Gabriel Windlin

What a Custom Linux Desktop Actually Looks Like

Unknown — Sat, 21 Feb 2026 00:00:00 +0000

Most people don't think about their desktop as something you can change. Windows manages your windows. macOS puts the dock somewhere. You drag things around. That's that.

On Linux, none of that is fixed. The thing that draws your windows, handles your taskbar, decides how you switch between apps — it's just a program. You can swap it out, or configure it yourself.

This post isn't "Linux is better." Here's what's possible and what it looks like in practice.

Hyprland</h2>
The centerpiece is Hyprland</a>, a tiling window manager. If you haven't used one, the concept takes five minutes to understand and then it's hard to go back.
In a normal desktop, windows float. You resize them, drag them, snap them to sides. In a tiling manager, windows arrange themselves. Open a terminal, full screen. Open a second, split in half. Open a third, thirds. Every pixel is used, nothing overlaps, and you move between them with the keyboard.
It sounds rigid. In practice, you stop thinking about window placement. The layout just happens. You think about your work instead.
Hyprland runs on Wayland (the modern display system) and is smooth with good performance. Everything—every keybinding, animation, behavior—is in a plain text config file.

Pywal</h2>
One of the cooler parts: Pywal</a>. It looks at your wallpaper, extracts colors, and applies them everywhere—terminal, status bar, window borders, app launcher. Change the wallpaper, the whole system recolors itself.
It's not just cosmetic. The desktop feels visually coherent without manual work. Pick an image, run one command, everything updates.

The Tools</h2>
Here's what actually runs day-to-day:
Kitty — GPU-accelerated terminal. Scrolling through thousands of lines of logs never stutters. Bonus: it displays images inline, which matters for the file manager below.
Zsh + Starship — Starship shows your directory, git branch, unstaged changes, language runtime. Small things, but they remove a lot of `git status</code> reflexes.`
`Yazi — A terminal file manager. Three-column layout, navigate with h/j/k/l</code>, previews files as you move. Text files show syntax-highlighted content. Images render inline via Kitty. PDFs, videos, archives — all previewed without opening anything. When you quit, your shell follows you to wherever you were.`
`Zoxide + fzf — cd</code> is tedious. Zoxide tracks which directories you visit and weights them by frequency. After a few days, j dot</code> jumps straight to ~/dotfiles</code>. Pair it with fzf and you get a fuzzy jump menu in under a second.`
`Zellij — Terminal multiplexer. Split panes, persistent sessions. You close your laptop, come back the next morning, reattach, and everything is exactly where you left it—server still running, logs still scrolling. Once you use it, a single terminal window feels wasteful.`
`Neovim (LazyVim) — A text editor operated almost entirely through keyboard shortcuts. No mouse, no menus. The learning curve is steep but the ceiling is high. LazyVim gives you LSP, fuzzy file finding, git integration, and syntax highlighting out of the box.`
`Zathura — PDF viewer controlled by keyboard. Open a slide deck, navigate with j/k</code>, search with /</code>. No mouse, no toolbar.`
`Aerc — Email in the terminal. Sounds like a joke until you realize how much calmer it is without a browser tab competing for your attention.`
`eza, bat, ripgrep, delta — Modern replacements for ls</code>, cat</code>, grep</code>, and git diffs. Colored output, icons, syntax highlighting, way faster. They don't change what you type. They just make the output worth reading.`
`The Status Bar</h2> Waybar shows active workspace, window title, CPU, network, volume, brightness, clock. Every element is positioned and formatted in a config file. Add a weather widget? Add a module. Remove the clock? Delete a line. Nothing is decided for you. Nothing is mysterious. It's all text files.`What If It Breaks?</h2> Arch has a reputation for being fragile. It can break, and you're more responsible for fixing it than on Ubuntu or macOS. That's a real tradeoff. The upside: when something breaks, you understand why. This setup includes an install.sh</code> script that automates everything — packages, config files, symlinks via GNU Stow. Fresh Arch install to fully working desktop takes under 20 minutes. The full configuration is on Codeberg</a> if you want to look through the files.



Building Kiroku-TUI: My First Rust TUI and Why I Needed It
Unknown — Wed, 18 Feb 2026 00:00:00 +0000
The Problem</h2>
I take a lot of notes. They're mostly markdown files — quick thoughts, daily logs, stuff I want to reference later. The problem is I live in the terminal, and most note apps assume you don't.</p>
I tried Obsidian. It's fine, I guess — the graph view is cool, plugins are everywhere, and I get why everyone recommends it. But I open terminals all day. The idea of clicking out of my workflow just to write a note felt wrong. I wanted something that lived where I already lived.</p>
Kiroku</h2>
So I built Kiroku</a></strong>. It's a TUI note manager. Fuzzy search, markdown preview, git sync for backup. No Electron, no GUI, just a binary that runs in any terminal.</p>
The workflow is basically: type to search, arrow keys to navigate, enter to open. Sort of like lazygit meets yazi, but for notes. That's really all I wanted.</p>
Learning Rust</h2>
I've been wanting to learn Rust for years. I'd do exercism problems, read the book, build tiny toy programs — and then forget everything a week later. I needed something real to work on.</p>
Kiroku was that thing. It's small enough to finish, but big enough to run into real problems:</p>

The borrow checker fought me on the search logic for way too long</li>
Working with serde_yaml</code> for frontmatter was straightforward once I figured out the right types</li>
ratatui</code> is well-documented but there's a learning curve to immediate-mode rendering</li>
</ul>
One specific moment: I spent 3 hours on a compiler error that turned out to be a missing &</code>. That's Rust in a nutshell for me so far.</p>
The Stack</h2>

ratatui</strong> — TUI framework. Good docs, active maintenance.</li>
fuzzy-matcher</strong> — For search. Simple, fast.</li>
serde</strong> + serde_yaml</strong> — Parsing YAML frontmatter</li>
</ul>
The search code is the part I'm most happy with:</p>
pub fn</span> update_search</span>(</span>&</span>mut</span> self</span>) {</span></span>
    if</span> self</span>.</span>search_query</span>.</span>is_empty</span>() {</span></span>
        self</span>.</span>notes </span>=</span> self</span>.</span>all_notes</span>.</span>clone</span>();</span></span>
    }</span> else</span> {</span></span>
        let</span> matcher</span> =</span> SkimMatcherV2</span>::</span>default</span>();</span></span>
        let mut</span> matches</span>:</span> Vec</span><</span>(</span>&</span>Note</span>,</span> i64</span>)</span>></span> =</span> self</span></span>
            .</span>all_notes</span></span>
            .</span>iter</span>()</span></span>
            .</span>filter_map</span>(</span>|</span>note</span>|</span> {</span></span>
                matcher</span></span>
                    .</span>fuzzy_match</span>(</span>&</span>note</span>.</span>title</span>,</span> &</span>self</span>.</span>search_query</span>)</span></span>
                    .</span>map</span>(</span>|</span>score</span>|</span> (</span>note</span>,</span> score</span>))</span></span>
            })</span></span>
            .</span>collect</span>();</span></span>
        matches</span>.</span>sort_by</span>(</span>|</span>a</span>,</span> b</span>|</span> b</span>.</span>1</span>.</span>cmp</span>(</span>&</span>a</span>.</span>1</span>));</span></span>
        self</span>.</span>notes </span>=</span> matches</span>.</span>into_iter</span>()</span>.</span>map</span>(</span>|</span>(</span>n</span>,</span> _</span>)</span>|</span> n</span>.</span>clone</span>())</span>.</span>collect</span>();</span></span>
    }</span></span>
}</span></span></code></pre>What's Next</h2>
I use Kiroku every day now. A few things I want to add:</p>

Calendar view for time-based note browsing</li>
Better file watcher performance (it chokes on large directories)</li>
Homebrew and AUR packages</li>
</ul>
If you try it and have thoughts, feel free to open an issue. Or don't — it's here if you need it.</p>
Source on Codeberg</a>.</p>



Our Place: Building a Shared Home Across 9,000 Kilometers
Unknown — Sat, 14 Feb 2026 00:00:00 +0000
The Vision: A Digital Apartment</h2>
Long-distance relationships are often lived through a fragmented series of apps: WhatsApp for chatting, Zoom for calls, and shared Google Sheets for travel planning. For our one-year anniversary, I wanted to create something more cohesive—a single "Digital Apartment" that serves as a shared space for my girlfriend in Brazil and me in Switzerland.</p>
"Our Place"</strong></a> is a React-based web application that mimics a physical home. By navigating through different "rooms," we can interact with shared memories, plan our future, and spend time together in real-time.</p>
A Guided Tour of the Apartment</h2>
The core of the app is the Room Controller</strong>. Instead of a traditional navigation bar, I used an AI-generated image of a cozy apartment as the interface. Using relative positioning and "Click Zones," different furniture items trigger specific modules, each living in its own dedicated component:</p>

The Fridge (Fridge.jsx</code>):</strong> A real-time, drag-and-drop canvas using @dnd-kit</code> for notes and photos. It features a Deep Dive Clipboard</strong> that serves a new thought-provoking question every day.</li>
The TV (LivingRoom.jsx</code>):</strong> A synchronized YouTube player where playback and video selection are synced in real-time across the ocean.</li>
The Couch (Couch.jsx</code>):</strong> Our digital photo album. It handles image uploads to Supabase Storage and uses the OpenCage API</strong> to geocode our memories.</li>
The Map (Timeline.jsx</code>):</strong> An interactive Leaflet</strong> map that pins our geocoded memories, followed by a vertical scrollytelling timeline of our relationship.</li>
The Window (FutureDreams.jsx</code>):</strong> A collaborative planner for travel bucket lists and long-term life goals, complete with progress bars and financial tracking.</li>
The PC (Arcade.jsx</code>):</strong> A "Relationship RPG" that gamifies our daily life, allowing us to earn gold for tasks and spend it on shared rewards.</li>
The Carpet (Milestones.jsx</code>):</strong> A digital ledger that tracks our relationship tenure down to the day and aggregates shared stats from across the app.</li>
The Title Area (Utilities.jsx</code>):</strong> A set of practical tools for international life, including dual clocks for Switzerland and Brazil and a real-time BRL/CHF currency converter.</li>
</ul>
This spatial metaphor makes the app feel less like a tool and more like a destination.</p>
Real-Time Presence: The Digital Fridge & Living Room</h2>
To make the apartment feel "alive," I used Supabase Realtime</strong> for instant synchronization across the Atlantic.</p>
The Fridge</h3>
The "Fridge" module is a drag-and-drop canvas using @dnd-kit</code>. We can leave sticky notes, "magnet" photos, and answer a Daily Deep Dive</strong> question. When one of us moves a note in Switzerland, it moves instantly on the screen in Brazil. It captures that small, domestic joy of leaving a note for your partner to find in the morning.</p>
The Virtual Living Room</h3>
Watching movies together is a staple of LDR life. I implemented a shared YouTube player using react-youtube</code>. The state (play/pause, current time, video URL) is persisted in a Supabase table. If I pause the video to grab a snack, her player pauses too, keeping us in perfect sync without the "3, 2, 1, click!" countdown.</p>
Mapping Our Journey: The Couch & Timeline</h2>
As we travel between Europe and South America, our history becomes a collection of coordinates.</p>

The Couch (Archive):</strong> When we upload a photo, I use the OpenCage Geocoding API</strong> to turn city names into latitude and longitude.</li>
The Timeline:</strong> These memories are then mapped using React-Leaflet</strong> on a dark-themed interactive map. Scrolling down reveals a vertical "Scrollytelling" timeline, where Framer Motion</strong> handles the animations to make the journey feel fluid.</li>
</ul>
Playful Logistics: The Relationship RPG</h2>
To make daily chores and goal-setting more engaging, I built the Relationship RPG</strong>. It’s a gamified task tracker where we earn "Gold" for completing shared or individual tasks. This currency can then be redeemed for custom rewards (like "Partner chooses the next movie").</p>
It’s backed by a straightforward PostgreSQL schema, but the impact on our daily interaction is significant—it turns the logistics of a relationship into a collaborative game.</p>
Conclusion</h2>
"Our Place" taught me that the best use of technology is often the most personal one. By using modern web abstractions like React and Supabase, I was able to build a functional, reliable, and emotionally resonant space that helps bridge the 9,000-kilometer gap.</p>
Happy Valentine's Day <3</p>



Deep Dive: What actually happens when you type 'ls'?
Unknown — Wed, 11 Feb 2026 00:00:00 +0000
The Interview Question</h2>
If you've ever interviewed for a systems engineering role, you know this question is coming: "What happens when you type ls -l</code> and hit Enter?"</em></p>
The typical answer? "The shell finds the ls</code> program and runs it."</em></p>
That'll get you a polite handshake and a "we'll be in touch."</p>
The actual answer? It involves shell parsers, $PATH</code> lookups, fork()</code> and execve()</code> system calls, the ELF loader, and filesystem inodes.</p>
Step 1: The Shell Reads Your Input</h2>
Before ls</code> does anything, your shell (Bash, Zsh, or Fish) is running a loop, waiting for your next command. It's blocking on a read()</code> system call to stdin (file descriptor 0).</p>
You type ls -l</code> and hit Enter.</p>
Tokenization:</strong> The shell splits your input into tokens: ["ls", "-l"]</code>.</p>
Alias expansion:</strong> Most systems alias ls</code> to ls --color=auto</code> by default, so your command actually becomes ["ls", "--color=auto", "-l"]</code>.</p>
Built-in check:</strong> The shell looks through its list of built-in commands (cd</code>, echo</code>, source</code>, etc.) to see if ls</code> is one of them. It's not, so we keep going.</p>
Step 2: Finding the Executable</h2>
Since ls</code> isn't a built-in, the shell needs to find the actual binary on disk. It doesn't search randomly; it walks through each directory in your $PATH</code> environment variable, in order.</p>
Let's say your $PATH</code> is /usr/local/bin:/usr/bin:/bin</code>. The shell checks:</p>

/usr/local/bin/ls</code> (not there)</li>
/usr/bin/ls</code> (found it)</li>
</ol>
It uses system calls like stat()</code> or access()</code> to check if the file exists and is executable.</p>
Optimization Note:</strong> Modern shells don't walk the $PATH</code> every time. They maintain a hash table of previously found commands. You can see this by running the hash</code> command in Bash. If you move a binary, you might see a "file not found" error because the shell is still looking at the old hashed path.</p>
Step 3: The Fork-Exec Dance</h2>
The shell cannot simply "become" ls</code>. If it did, you would lose your shell session entirely. Instead, it creates a copy of itself.</p>
The Fork</h3>
The shell calls fork()</code>, which creates a new process that is an exact duplicate of the parent. Now you have two processes running the same shell code:</p>

Parent process (your shell):</strong> Calls wait()</code> and blocks until the child finishes.</li>
Child process:</strong> Currently running shell code, but preparing to switch.</li>
</ul>
The Exec</h3>
The child immediately calls execve("/usr/bin/ls", argv, envp)</code> where:</p>

argv</code> is ["ls", "-l"]</code></li>
envp</code> contains your environment variables (HOME, PATH, USER, etc.)</li>
</ul>
When execve</code> is called, it instructs the kernel to:</p>

Destroy</strong> the child's current memory space.</li>
Load</strong> the /usr/bin/ls</code> binary from disk into memory.</li>
Jump</strong> to the entry point of the new program.</li>
</ol>
If you run strace</code> to track system calls, you can see this transition clearly:</p>
# strace -f -e trace=execve bash -c "ls -l"</span></span>
execve("/usr/bin/bash",</span> [</span>"bash"</span>,</span> "-c", "ls -l"], ...</span>) = 0</span></span>
[</span>pid 1234</span>]</span> execve(</span>"/usr/bin/ls",</span> [</span>"ls"</span>,</span> "-l"], ...</span>) = 0</span></span></code></pre>
The child process retains the same process ID but runs completely different code. This fork-exec model is an elegant way to handle process creation in Unix-like systems.</p>
Step 4: The Dynamic Linker</h2>
Most modern programs are not statically compiled; they depend on shared libraries like libc.so</code>. Before ls</code> can run, the kernel loads the dynamic linker (usually /lib64/ld-linux-x86-64.so.2</code>).</p>
The linker's job is to:</p>

Parse the ELF binary to find its dependencies.</li>
Load shared libraries like libc.so</code> and libselinux.so</code> into memory.</li>
Resolve symbols, connecting printf</code> calls in ls</code> to the actual printf</code> implementation in libc</code>.</li>
</ul>
Only after this setup is the main()</code> function of ls</code> called.</p>
Step 5: Reading the Directory</h2>
Finally, ls</code> performs its primary task. It cannot read the disk directly, as that is the kernel's domain. Instead, it makes a series of system calls:</p>
openat()</code></strong> opens the directory (typically .</code>, your current working directory).</p>
getdents64()</code></strong> reads directory entries from the kernel. This provides a list of filenames and their associated inodes (filesystem metadata).</p>
stat()</code></strong> gets called on every file. Because you used -l</code>, ls</code> needs detailed information:</p>

Permissions (rwxr-xr-x</code>)</li>
Owner and group (UID/GID)</li>
File size</li>
Modification timestamp</li>
</ul>
You can see this "stat storm" in strace</code> output:</p>
openat(AT_FDCWD, ".", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3</span></span>
getdents64(3, /* 10 entries */, 32768)  = 312</span></span>
newfstatat(AT_FDCWD, "file1.txt", {st_mode=S_IFREG|0644, st_size=1024, ...}, 0) = 0</span></span>
newfstatat(AT_FDCWD, "file2.md", {st_mode=S_IFREG|0644, st_size=2048, ...}, 0) = 0</span></span></code></pre>Step 6: Writing the Output</h2>
ls</code> formats this information and calls write()</code> on file descriptor 1 (stdout). The kernel takes those bytes and sends them to your terminal emulator for rendering.</p>
TTY Detection:</strong> ls</code> uses the isatty()</code> library function to see if its output is a terminal. If it is, it provides colors and columns. If the output is a pipe (like ls | cat</code>), it strips colors and switches to one-file-per-line for better script compatibility.</p>
When the child process exits with status 0 (success), the parent shell is woken up from its wait()</code> call. The shell prints a new prompt, and the cycle repeats.</p>

Why This Matters</h2>
This entire process, from keystroke to output, happens in milliseconds. Understanding it is important for several reasons:</p>

Debugging:</strong> When a command fails, knowing the sequence helps identify the cause. Is it a $PATH</code> issue, a permission problem, or a missing shared library?</li>
Performance:</strong> Every stat()</code> call is expensive. This explains why ls</code> on large directories can be slow. Furthermore, every system call involves a context switch from user-space to kernel-space. In a post-Spectre/Meltdown environment (with KPTI enabled), these transitions are even more costly, making syscall minimization a key optimization.</li>
Security:</strong> The fork-exec model creates clear boundaries. Child processes inherit file descriptors, environment variables, and security contexts. Understanding this is essential for writing secure software.</li>
</ul>
Next time someone asks you what happens when you type ls</code>, you'll have a more complete answer.</p>



De-Magicking AI: Writing a Neural Network in Pure C
Unknown — Sun, 08 Feb 2026 00:00:00 +0000
Everyone is talking about AI right now. But for most developers, "doing AI" just means importing a Python library and calling a function. It feels like magic.</p>
I don't like magic. I like logic.</p>
I wanted to understand why</em> it works—not just theoretically, but at the instruction level. So, I decided to do something slightly masochistic: I built a fully functional, configurable neural network in pure C. No PyTorch, no TensorFlow, just me and math.h</code>.</p>
The "Why": Logic vs. Magic</h2>
The motivation was simple: pure curiosity mixed with a challenge. When you use a high-level library, you take the gradient descent and backpropagation for granted. You trust the "black box."</p>
By forcing myself to implement it in C, I had to confront the reality of what a neural network actually is: a massive pile of linear algebra and calculus. There is no garbage collector to save you, and there is no tensor.backward()</code> to do the math for you.</p>
The Architecture</h2>
I didn't want to hardcode a simple XOR solver. I wanted a generic engine. My implementation supports:</p>

Dynamic Topology:</strong> Configurable input, hidden, and output sizes.</li>
Activations:</strong> Sigmoid, ReLU, Leaky ReLU, Tanh, and Linear.</li>
Loss Functions:</strong> MSE, Binary Cross-Entropy, and MAE.</li>
Optimizers:</strong> Momentum and Learning Rate Decay.</li>
</ul>
Here is how the network looks in memory. Notice the heavy use of double pointers (double**</code>)—this was necessary to create dynamic 2D arrays for the weights and gradients.</p>
typedef struct</span> {</span></span>
    int</span> input_size</span>;</span></span>
    int</span> hidden_size</span>;</span></span>
    int</span> output_size</span>;</span></span>
</span>
    // Weights and biases</span></span>
    double</span>**</span> w1</span>;</span></span>
    double</span>*</span> b1</span>;</span></span>
    double</span>**</span> w2</span>;</span></span>
    double</span>*</span> b2</span>;</span></span>
</span>
    // Activations</span></span>
    double</span>*</span> hidden</span>;</span></span>
    double</span>*</span> output</span>;</span></span>
</span>
    // Gradients & Momentum</span></span>
    double</span>**</span> dw1</span>;</span></span>
    double</span>**</span> dw2</span>;</span></span>
    double</span> momentum</span>;</span></span>
}</span> NeuralNetwork</span>;</span></span>
</span></code></pre>The Math: No Libraries, Just Calculus</h2>
Implementing this required translating vector calculus directly into C loops. The code isn't just moving data; it's physically calculating the Chain Rule step-by-step.</p>
1. The Forward Pass (Prediction)</strong></p>
First, we compute the weighted sum of inputs plus a bias (the linear step), and then "squash" it using an activation function like Sigmoid to introduce non-linearity:</p>
$$
Z = W \cdot X + b
$$</p>
$$
A = \sigma(Z) = \frac{1}{1 + e^{-Z}}
$$</p>
2. The Backward Pass (Learning)</strong></p>
This is where the magic (or pain) happens. We calculate how much each specific weight contributed to the total error using the Chain Rule:</p>
$$
\frac{\partial L}{\partial W} = \frac{\partial L}{\partial A} \cdot \frac{\partial A}{\partial Z} \cdot \frac{\partial Z}{\partial W}
$$</p>
3. The Update (Gradient Descent)</strong></p>
Finally, we nudge the weights in the opposite direction of the gradient to minimize error, scaled by a learning rate ($\eta$):</p>
$$
W_{new} = W_{old} - \eta \cdot \nabla L
$$</p>
In Python, this is one line of code. In C, that single update equation becomes a carefully managed nested for</code> loop handling pointers to gradient arrays.</p>
The Friction: Pointers and Memory</h2>
The hardest part wasn't the math itself; it was the memory management. In Python, you create a list and move on. In C, if you want a dataset, you have to malloc</code> every single row.</p>
If you don't plan your memory usage ahead of time, you end up with segmentation faults or memory leaks. You have to be intentional. Every time I calculate a gradient, I have to know exactly where that double</code> is going to live.</p>
The "Aha!" Moment</h2>
The most satisfying part of this project wasn't writing the code—it was running it. Because it's C, it is blazing fast. I built a CLI interface that lets me tweak hyperparameters via flags (-h</code> for hidden size, -lr</code> for learning rate) and watch the training in real-time.</p>
Here is what it looks like when the network learns the XOR</strong> function (a classic non-linear problem) in milliseconds:</p>
$</span> ./nn -e</span> 5000</span> -l</span> 0.1</span> -h</span> 8</span> -d xor -ha relu -oa sigmoid -loss bce -wd</span> 0.001</span> -v</span></span>
</span>
dataset</span> info:</span></span>
  type</span>: xor</span></span>
  total</span> samples:</span> 100</span></span>
  training</span> samples:</span> 80</span></span>
  test</span> samples:</span> 20</span></span>
</span>
starting</span> training...</span></span>
epoch</span> 0/5000</span> |</span> train</span> loss:</span> 0.697071</span> |</span> test</span> loss:</span> 0.713845</span></span>
epoch</span> 100: learning rate decayed to</span> 0.099500</span></span>
...</span></span>
final</span> results:</span></span>
  training</span> loss:</span> 0.000590</span></span>
  test</span> loss:</span> 0.001088</span></span>
  training</span> accuracy: 100.00%</span> (80/80)</span></span>
  test</span> accuracy: 100.00%</span> (20/20)</span></span>
</span>
sample</span> predictions:</span></span>
input:</span> [0.071,</span> 0.926]</span> -</span>></span> output:</span> 0.9940</span> (expected:</span> 1.0000</span>) -</span>></span> class: 1 (</span>expected:</span> 1</span>) ✓</span></span>
input:</span> [-0.045,</span> 0.077]</span> -</span>></span> output:</span> 0.0000</span> (expected:</span> 0.0000</span>) -</span>></span> class: 0 (</span>expected:</span> 0</span>) ✓</span></span>
</span></code></pre>
Seeing the loss drop from 0.69</code> to 0.0005</code> in the terminal proves that the math I wrote by hand is actually working. The network "learned" that [0, 1]</code> outputs 1</code> and [0, 0]</code> outputs 0</code>.</p>
Dealing with Complexity: The Circle Problem</h2>
XOR is cool, but I wanted to see if my C engine could handle messy classification data. I generated a dataset of points inside and outside a circle (non-linearly separable) and added noise.</p>
The network struggled initially, but after tuning the hidden layer size and switching to ReLU</code>, it converged.</p>
$</span> ./nn -d circle_enhanced -n</span> 2000</span> -ha relu -oa sigmoid -loss bce</span></span>
...</span></span>
sample</span> predictions:</span></span>
input:</span> [-0.281,</span> -0.996</span>] -</span>></span> output: 0.4922 (</span>expected:</span> 0.0000</span>) -</span>></span> class: 0 (</span>expected:</span> 0</span>) ✓</span></span>
input:</span> [-0.192,</span> 0.158]</span> -</span>></span> output:</span> 0.4922</span> (expected:</span> 1.0000</span>) -</span>></span> class: 0 (</span>expected:</span> 1</span>) ✗</span></span>
</span></code></pre>
You can see it's not perfect (it misses edge cases), but that's the reality of ML. It’s probabilistic, not deterministic.</p>
Conclusion</h2>
Building this taught me that there is no magic in AI. It's just:</p>

Forward Pass:</strong> Dot products and activation functions.</li>
Loss Calculation:</strong> How wrong were we?</li>
Backward Pass:</strong> Using derivatives to nudge weights in the opposite direction of the error.</li>
</ol>
Check out the full source code on my Codeberg</a>.</p>



C vs Node.js: I fought the Event Loop, and the Loop (almost) won
Unknown — Tue, 03 Feb 2026 00:00:00 +0000
The Hypothesis</h2>
I love C. It’s raw, it’s low-level, and it forces you to understand memory. Naturally, I assumed that a raw TCP server written in C would obliterate a server written in JavaScript (Node.js).</p>
Node.js runs on V8 (a JIT engine) and carries the weight of a runtime. C runs directly on the metal. The winner seemed obvious.</p>
I set up a benchmark between my Surface Pro 9</strong> (Client) and my Ubuntu Homelab</strong> (Server) over a Tailscale VPN.</p>
Attempt 1: Node.js (The Baseline)</h2>
I ran a standard "Hello World" in Node.js, which uses the Event Loop</strong> (Non-blocking I/O) by default.</p>

Requests/Sec:</strong> ~15,860</li>
Errors:</strong> 0</li>
</ul>
The Reality Check:</strong> Node.js didn't just win; it destroyed my C server. It handled concurrency effortlessly because it never waits for I/O.</p>
Attempt 2: The Naive C Server</h2>
My first attempt was a standard, blocking C server. It used accept()</code>, write()</code>, and close()</code> in a simple while</code> loop.</p>
I hit it with wrk</code> (12 threads, 400 connections).</p>

Requests/Sec:</strong> ~6,500</li>
Errors:</strong> 160,000+ (Socket Read Errors)</li>
</ul>
The Failure:</strong> It was a disaster. Because the server processed requests one by one (Blocking I/O), the OS connection queue filled up instantly, and packets were dropped.</p>
Attempt 3: The Redemption (Single-Threaded Epoll)</h2>
I wasn't going to let C lose. I rewrote the server using epoll</code></strong>, the Linux kernel's high-performance notification mechanism. I also implemented HTTP Keep-Alive</strong> to stop closing sockets unnecessarily.</p>

Requests/Sec:</strong> ~13,580</li>
Errors:</strong> 0</li>
</ul>
The Frustration:</strong> I fixed the stability, but I was still</em> slower than Node.js. Why? Because libuv</code> (Node's C core) and V8 are hyper-optimized. My single-threaded C code just couldn't keep up with 15 years of Google engineering.</p>
Attempt 4: The Nuclear Option (Multi-Threading)</h2>
Node.js is single-threaded. My server has 4 cores. It was time to cheat (or rather, use my hardware).</p>
I used pthread</code> to spin up 4 worker threads. But how do you share a port? I used SO_REUSEPORT</code>, a Linux kernel flag that allows multiple sockets to bind to port 8080 simultaneously. The kernel handles the load balancing.</p>

Requests/Sec:</strong> ~17,060</strong></li>
Errors:</strong> 0</li>
</ul>
The Verdict</h2>
We finally did it. We beat JavaScript.</p>
Implementation</th> Req/Sec</th> Notes</th></tr></thead>

Node.js</strong></td> 15,859</td> The Gold Standard</td></tr>
Blocking C</strong></td> 6,529</td> 100% Fail rate</td></tr>
Epoll C (1 Thread)</strong></td> 13,578</td> Faster, but not fast enough</td></tr>
Epoll C (4 Threads)</strong></td> 17,059</strong></td> Victory</strong></td></tr>
</tbody></table>
Conclusion</h2>
I started this experiment to prove C was faster. Instead, I learned that Architecture > Language</strong>.</p>
A badly written C program will always lose to a well-optimized Runtime. Even a well-written</em> single-threaded C program might lose to the V8 engine. But if you dig deep enough into the OS using epoll</code>, SO_REUSEPORT</code>, and threads you can eventually reclaim the crown.</p>
Check out the source code for the final server on my Codeberg</a>.</p>



The Invisible Navigator: Why I Revisit A* in Java
Unknown — Sat, 31 Jan 2026 00:00:00 +0000
If you drove somewhere today, you likely trusted a blue line on your phone screen. You didn't question it. You just turned left when it said turn left.</p>
But how did it know? How did it sift through millions of road segments, traffic lights, and speed limits to find the single</em> optimal route in milliseconds?</p>
It wasn't magic. It was a graph traversal algorithm. specifically, a heuristic search likely derived from A* (A-Star)</strong>.</p>
We will be doing this in Java</strong>, which was my first programming language, and despite the hate it gets, its strict Object-Oriented nature makes it the perfect vessel for complex algorithms.</p>
The Logic: Why Dijkstra Wasn't Enough</h2>
The classic algorithm for finding the shortest path is Dijkstra's Algorithm</strong>. It works by exploring every</em> possible direction equally, expanding outward like a ripple in a pond until it hits the target.</p>
This is guaranteed to find the shortest path, but it's wasteful. If you are in Zurich and want to go to Paris (West), there is no point in checking roads leading to Vienna (East).</p>
Enter A* (A-Star).</strong></p>
A* introduces a "brain" to the process. It doesn't just look at the distance traveled ($g$); it also estimates the distance remaining ($h$, or the heuristic</strong>).</p>
The core math is elegant in its simplicity:</p>
$$f(n) = g(n) + h(n)$$</p>

$g(n)$</strong>: The actual cost to get from the start to node $n$ (traffic, distance).</li>
$h(n)$</strong>: The estimated "crow flies" distance from $n$ to the goal.</li>
</ul>
By minimizing $f(n)$, the algorithm prioritizes paths that are both short and</em> moving in the right direction.</p>
The Code: Java's OOP Power</h2>
I implemented this in Java because the PriorityQueue</code> and Class</code> structures handle the complexity cleanly. Here is the core Node</code> class that implements Comparable</code>—this is what allows Java to instantly sort the most promising paths to the top of the pile.</p>
static class</span> Node</span> implements</span> Comparable</span><</span>Node</span>> {</span></span>
    int</span> id</span>;</span></span>
    int</span> g</span>;</span> // Cost from start</span></span>
    int</span> h</span>;</span> // Heuristic (guess) to end</span></span>
    int</span> f</span>;</span> // Total score (g + h)</span></span>
</span>
    Node</span>(</span>int</span> id</span>,</span> int</span> g</span>,</span> int</span> h</span>) {</span></span>
        this</span>.</span>id</span> =</span> id</span>;</span></span>
        this</span>.</span>g</span> =</span> g</span>;</span></span>
        this</span>.</span>h</span> =</span> h</span>;</span></span>
        this</span>.</span>f</span> =</span> g </span>+</span> h</span>;</span></span>
    }</span></span>
</span>
    // This is the magic: Java automatically sorts by 'f' score</span></span>
    @Override</span></span>
    public int</span> compareTo</span>(</span>Node</span> other</span>) {</span></span>
        return</span> Integer</span>.</span>compare</span>(</span>this</span>.</span>f</span>,</span> other</span>.</span>f</span>);</span></span>
    }</span></span>
}</span></span>
</span></code></pre>
And here is the search loop. Unlike the raw pointer arithmetic of my C projects, this reads almost like English.</p>
while</span> (</span>!</span>pq</span>.</span>isEmpty</span>()) {</span></span>
    Node</span> current</span> =</span> pq</span>.</span>poll</span>();</span> // Get the most promising node</span></span>
</span>
    if</span> (</span>current</span>.</span>id</span> ==</span> goalNode</span>)</span> return</span> reconstructPath</span>(</span>parent</span>,</span> goalNode</span>);</span></span>
</span>
    // If we found a shorter path to a neighbor, record it</span></span>
    if</span> (</span>newG </span><</span> dist</span>[</span>v</span>]) {</span></span>
        dist</span>[</span>v</span>]</span> =</span> newG</span>;</span></span>
        parent</span>[</span>v</span>]</span> =</span> u</span>;</span></span>
        pq</span>.</span>add</span>(</span>new</span> Node</span>(</span>v</span>,</span> newG</span>,</span> h</span>[</span>v</span>]));</span></span>
    }</span></span>
}</span></span>
</span></code></pre>The Visualization: Watching it Think</h2>
The real beauty of A* emerges when you visualize its decision-making. Unlike Dijkstra's uniform expansion, A* is drawn toward the goal like a magnet. Let's trace through a simple grid.</p>
Consider this 4x4 world. S</code> is start, G</code> is goal, #</code> is a wall. The heuristic $h$ is the Manhattan distance (sum of horizontal and vertical steps remaining).</p>
Initial State:</span></span>
S . . #</span></span>
. # . .</span></span>
. . # .</span></span>
# . . G</span></span></code></pre>
Our Java PriorityQueue</code> starts with the S</code> node at (0,0). Let's label each explored node with its [f = g + h]</code> score.</p>
Step 1:</strong> Expand S</code> (0,0). Its neighbors are (0,1) and (1,0).</p>

(0,1): g=1</code> (one step from S), h=4</code> (to G at (3,3)), so f=5</code></li>
(1,0): g=1</code>, h=5</code>, so f=6</code>
PriorityQueue now: [(0,1):5, (1,0):6]</code> ← Lowest f</code> is first.</li>
</ul>
Step 2:</strong> Expand the most promising node, (0,1) f=5</code>. Its open neighbor is (0,2).</p>

(0,2): g=2</code>, h=3</code>, so f=5</code>
Queue: [(0,2):5, (1,0):6]</code> ← A tie! Our compareTo</code> method will take (0,2), but both have equal priority.</li>
</ul>
Step 3:</strong> Expand (0,2) f=5</code>. Its open neighbor is (1,2).</p>

(1,2): g=3</code>, h=2</code>, so f=5</code>
Queue: [(1,2):5, (1,0):6]</code></li>
</ul>
Step 4:</strong> Expand (1,2) f=5</code>. Critical choice! Neighbors: (1,3) is a wall, (2,2) is a wall, (0,2) is visited. Only (2,1) is open.</p>

(2,1): g=4</code>, h=2</code>, so f=6</code>
Queue: [(1,0):6, (2,1):6]</code> ← Notice the "backtrack": (1,0) from Step 1 is now just as promising. The algorithm isn't stubborn; it reconsiders.</li>
</ul>
Step 5:</strong> Expand (1,0) f=6</code>. Its neighbor (2,0) opens a new frontier.</p>

(2,0): g=2</code>, h=3</code>, so f=5</code> ← A better path is found!
Queue: [(2,0):5, (2,1):6]</code></li>
</ul>
Step 6:</strong> Expand (2,0) f=5</code>. This leads to (3,0) which is a wall, and (2,1) which is already queued. The algorithm proceeds, navigating around the obstacles until...</p>
Final Path:</strong> The algorithm will find this optimal 6-step path, having explored far fewer nodes than Dijkstra would have:</p>
S 1 2 #</span></span>
1 # 3 4</span></span>
2 5 # 5</span></span>
# 6 7 G</span></span></code></pre>A Note on "Greed" vs "Structure"</h2>
A* is often called a "Best-First" search, which can feel greedy, it always grabs the shiny, promising node next. But sometimes, being greedy isn't the answer.</p>
It's important to mention algorithms like Prim's</strong> or Kruskal's</strong> (used for Minimum Spanning Trees). Unlike A*, which finds a single path for a single agent, MSTs are about infrastructure. They connect *all* nodes with the minimum total wire/road length.</p>
If A* is the GPS in your car, MST is the civil engineer who decided where to pave the roads in the first place.</p>
Why Java?</h2>
There is a reason Big Tech still runs on Java. When you are processing graph data with millions of nodes (think social networks or street maps), you need the strictness of strong typing and the reliability of the JVM.</p>
Writing this in C would have required manually implementing a Priority Queue and managing heap memory for every node expansion. Writing it in Python would have been slow. Java hits that sweet spot: high-level abstractions with near-native performance.</p>



The Only Linux Course You Need: OverTheWire Bandit (0-10)
Unknown — Wed, 28 Jan 2026 00:00:00 +0000
If you ask a beginner how to start hacking, they usually ask "which tool should I download?" They want the "Magic Button."</p>
But relying on automated tools without understanding the underlying system is like being a pilot who only knows how to use autopilot. If the system fails, or if the tool doesn't work, you crash. You need to know how to fly manually.</p>
That is why I recommend OverTheWire: Bandit</strong> to everyone. It isn't just a security game; it is a trial-by-fire Linux administration course. It forces you to understand:</p>

The Filesystem Hierarchy:</strong> Why are things in /var</code> vs /tmp</code>?</li>
Permissions:</strong> Who owns what, and why does it matter?</li>
Piping:</strong> How to chain small tools to solve big problems.</li>
</ul>
Below is my walkthrough for Levels 0–10. I have blurred the flags so you can't just copy-paste them. You have to run the commands yourself.</p>
The Setup</h2>
I keep it simple:</p>

Terminal:</strong> On the right half of my screen.</li>
Notes:</strong> A simple .txt</code> file on the left where I paste the passwords as I find them.</li>
Scripting:</strong> If bash</code> gets too messy, I switch to Python. For most of the first 10 levels, the shell is king, but I'll show you where Python becomes cleaner.</li>
</ol>

Levels 0-3: Learning to Walk</h2>
The first few levels are about muscle memory: ls</code>, cd</code>, and cat</code>.</p>
Level 0 → 1</h3>
Goal:</strong> Log in via SSH.
We connect to bandit.labs.overthewire.org</code> on port 2220</code>.</p>
ssh</span> bandit0@bandit.labs.overthewire.org -p</span> 2220</span></span>
# Password: bandit0</span></span>
</span></code></pre>
Once in, we check the files.</p>
ls</span></span>
cat</span> readme</span></span>
</span></code></pre>
Flag:</strong> NH2SXQwcBdpmTEzi3bvBHMMtH66vVXjL</span></p>
Level 1 → 2 (The "Dash" Problem)</h3>
Goal:</strong> Read a file named -</code>.
If you try cat -</code>, the program thinks you are trying to read from stdin</code> (standard input). You have to explicitly tell the shell "this is a file path" using ./</code> (which means "current directory").</p>
cat</span> ./-</span></span>
</span></code></pre>
Flag:</strong> rRGizSaX8Mk1RTb1CNQoXTcYZWU6lgzi</span></p>
Level 2 → 3 (Spaces in Filenames)</h3>
Goal:</strong> Read a file named spaces in this filename</code>.
Spaces separate arguments in Bash. To tell Bash this is one single argument, we use quotes or escape characters.</p>
cat</span> "spaces in this filename"</span></span>
# OR</span></span>
cat</span> spaces</span>\ </span>in</span>\ </span>this</span>\ </span>filename</span></span>
</span></code></pre>
Flag:</strong> aBZ0W5EmUfAf7k76VKKJ7px84k5ePPRa</span></p>

Levels 4-6: The Power of find</code></h2>
Now we stop looking at files and start searching</em> for them.</p>
Level 4 → 5</h3>
Goal:</strong> Find the only human-readable file in the inhere</code> directory.
There are multiple files named -file00</code>, -file01</code>, etc. Most are binary garbage. We can use the file</code> command to see the data type of every file at once.</p>
file</span> ./inhere/</span>*</span></span>
</span></code></pre>
Look for the one that says ASCII text</code>.</p>
Flag:</strong> 4oQYVPkxZOOEOO5pTW81FB8j8lxXGUQw</span></p>
Level 5 → 6</h3>
Goal:</strong> Find a file that is 1033 bytes</strong>, not executable</strong>, and owned by group bandit6</strong>.
This is where find</code> shines. We can filter by properties, not just names.</p>
find</span> . -type f -size 1033c ! -executable -group bandit6</span></span>
</span></code></pre>
(Note: 1033c</code> means bytes. 1033k</code> would be kilobytes!)</em></p>
Flag:</strong> HWasnPhtq9AVKe0dmk45nxy20cvUa6Cu</span></p>
Level 6 → 7 (The Filter)</h3>
Goal:</strong> The file is somewhere on the server (not just in the current folder), owned by user bandit7</strong>, group bandit6</strong>, and 33 bytes</strong> large.</p>
This is the first real hurdle for many. You have to search the entire</em> drive (/</code>), which means you are going to get thousands of "Permission Denied" errors from looking in folders you don't have access to.</p>
If you just run the command, the flag will be buried in error messages. We need to redirect those errors (stderr</code>, file descriptor 2) into the void (/dev/null</code>).</p>
find</span> / -user bandit7 -group bandit6 -size 33c</span> 2></span>/dev/null</span></span>
</span></code></pre>
This command is a synthesis of three concepts:</p>

Scope:</strong> Searching from root /</code>.</li>
Filtering:</strong> Combining user, group, and size flags.</li>
Stream Redirection:</strong> Cleaning the output so only the success is visible.</li>
</ol>
Flag:</strong> morbNTDkSW6jIlUc0ymOdMaLnOlFVAaj</span></p>

Levels 7-10: Text Wrangling</h2>
We found the files; now we need to process the text inside</em> them.</p>
Level 7 → 8</h3>
Goal:</strong> The password is next to the word "millionth".
We use grep</code> (Global Regular Expression Print).</p>
grep</span> "millionth" data.txt</span></span>
</span></code></pre>
Flag:</strong> dfwvzFQi4mU0wfNbFOe9RoWskMLg7eEc</span></p>
Level 8 → 9</h3>
Goal:</strong> The password is the only line of text that occurs only once.
To find a unique line, we first need to sort them. Why? Because uniq</code> only compares adjacent lines. It can't detect duplicates that are separated. Sorting brings all identical lines together.</p>
sort</span> data.txt</span> |</span> uniq</span> -u</span></span>
</span></code></pre>
Python Alternative:</strong> If you want to see where Python becomes cleaner, here's how you could solve this with a one-liner:</p>
python3</span> -</span>c</span> "from collections import Counter; print([k for k,v in Counter(open('data.txt').readlines()).items() if v==1][0].strip())"</span></span></code></pre>
This uses Python's Counter</code> to count occurrences without needing to sort first. For simple shell tasks, sort | uniq</code> is faster to type, but when dealing with more complex data transformations, Python's data structures give you more power.</p>
Flag:</strong> 4CKMh1JI91bUIZZPXDqGanal4xvAg0JM</span></p>
Level 9 → 10</h3>
Goal:</strong> One of the few human-readable strings in a binary file, preceded by several =</code> characters.
If you cat</code> a binary file, you might crash your terminal. Use strings</code> to pull out the text, then pipe it to grep.</p>
strings</span> data.txt</span> |</span> grep</span> "==="</span></span>
</span></code></pre>
Flag:</strong> FGUW5il8JNE7q19ksvT6E3RhhE5gQnwj</span></p>
Level 10 → 11</h3>
Goal:</strong> The file contains base64 encoded data.
Base64 is not encryption; it's encoding. It's easily reversible.</p>
base64</span> -d data.txt</span></span>
</span></code></pre>
Flag:</strong> dtR173fZKb0RRsDFSGsg2RWnpNVj3qRr</span></p>

Conclusion</h2>
At this point, you aren't "hacking" yet. You're just administrating. But these skills are the foundation. If you can't filter a text stream or find a config file by its permissions, you can't escalate privileges.</p>
Next time, we'll dive into Level 11-20</strong>, where we start dealing with networking, compression, and SSH keys.</p>



Smart Cracking: Teaching Python to 'Guess' Like a Human
Unknown — Sat, 24 Jan 2026 00:00:00 +0000
The Problem with Brute Force</h2>
If you try to crack a password by guessing aaaaa</code>, then aaaab</code>, you are fighting against entropy. This is inefficient because humans don't type random characters; we follow predictable patterns like Password123</code>, Welcome2026</code>, or ilovecoffee</code>.</p>
If I know you typed P-a-s-s</code>, there is a statistical near-certainty that the next letter is w</code>. A "dumb" brute-forcer would try P-a-s-s-a</code>, P-a-s-s-b</code>, and waste thousands of cycles before hitting the correct character. I wanted to build a tool that "understands" these patterns, so I implemented a Markov Chain engine in my security toolkit, Sec-Suite</strong>.</p>

The Theory: Markov Chains</h2>
At its core, a Markov Chain is a stochastic model where the probability of each event depends only on the state attained in the previous event. For password cracking, we look at a sequence of characters to predict the most likely successor.</p>
Mathematically, the probability of the next character occurring is based on the previous characters:</p>
$$P(X_{n} = x | X_{n-3}, X_{n-2}, X_{n-1})$$</p>
In my implementation, I defined a "state" as a sequence of 3 characters, known as an Order-3</strong> chain. This effectively creates a 4-gram</strong> model: it looks at a 3-character "window" to guess the 4th.</p>

The Logic: A "Sliding Window" of Probability</h2>
The engine works in two distinct phases: Training</strong> and Generation</strong>.</p>
1. Training (Building the Brain)</h3>
I feed the model a wordlist, such as rockyou.txt</code>. It slides a window of size 3 over every password, recording what character comes next.</p>
def</span> train</span>(</span>self</span>,</span> passwords</span>:</span> List</span>[</span>str</span>]):</span></span>
    for</span> password</span> in</span> passwords</span>:</span></span>
        for</span> i</span> in</span> range</span>(</span>len</span>(</span>password</span>)</span> -</span> self</span>.</span>order</span>):</span></span>
            # The "State" (e.g., "Pas")</span></span>
            state</span> =</span> password</span>[</span>i</span> :</span> i</span> +</span> self</span>.</span>order</span>]</span></span>
            # The "Next" (e.g., "s")</span></span>
            next_char</span> =</span> password</span>[</span>i</span> +</span> self</span>.</span>order</span>]</span></span>
</span>
            if</span> state</span> not in</span> self</span>.</span>model</span>:</span></span>
                self</span>.</span>model</span>[</span>state</span>]</span> =</span> []</span></span>
            # Record that "s" can follow "Pas"</span></span>
            self</span>.</span>model</span>[</span>state</span>].</span>append</span>(</span>next_char</span>)</span></span></code></pre>2. Generation (The Statistical Guess)</h3>
The beauty of this approach is that I don't need complex math libraries to calculate weights. By storing every occurrence in a list, random.choice()</code> handles the probability distribution automatically.</p>
If the model sees Password</code> five times and Passcode</code> twice, the list for the state ass</code> looks like this: ['w', 'w', 'w', 'w', 'w', 'c', 'c']</code>. By using a list rather than a dictionary of percentages, we avoid manual math—random.choice()</code> simply has a 71.4%</strong> chance of picking w</code> based on its frequency.</p>
def</span> generate_password</span>(</span>self</span>,</span> max_length</span>:</span> int</span> =</span> 20</span>) -></span> str</span>:</span></span>
    while</span> len</span>(</span>password</span>)</span> <</span> max_length</span>:</span></span>
        state</span> =</span> password</span>[</span>-</span>self</span>.</span>order</span> :]</span></span>
        # Frequency in the list = Probability of selection</span></span>
        next_char</span> =</span> random</span>.</span>choice</span>(</span>self</span>.</span>model</span>[</span>state</span>])</span></span>
        password</span> +=</span> next_char</span></span></code></pre>The Bottleneck: Python's GIL</h2>
I initially included a multi-threaded cracker to generate and test passwords in parallel. However, I hit a wall called the Global Interpreter Lock (GIL)</strong>. In Python, the GIL prevents multiple native threads from executing bytecodes at once For CPU-bound tasks like password hashing, threading is essentially an "illusion of parallelism"—my script was barely faster than a single-threaded version.</p>
The Path Forward: Multiprocessing vs. C</h3>
To truly scale, I have two options:</p>

multiprocessing</code></strong>: Use Python’s multiprocessing</code> module to side-step the GIL by spawning separate memory spaces for each CPU core.</li>
The C Switch</strong>: Port the hashing and generation logic to C/C++.</li>
</ol>
While multiprocessing</code> is a great intermediate step, Python is for logic; C is for speed</strong>. To build a production-grade cracker, the engine needs to live closer to the bare metal.</p>

Why Serialize? (.pkl</code>)</h2>
Training on rockyou.txt</code> (14 million passwords) takes significant time. I used Python's pickle</code> module to dump the memory state into a .pkl</code> file so the "brain" loads instantly on startup.</p>

⚠️ A Note on Security</h3>
While pickle</code> is convenient, it is insecure</strong> against erroneous or malicious data. Unpickling a crafted file can lead to Remote Code Execution (RCE)</strong>. For a public security tool, a safer alternative like JSON or a custom binary format is preferred.</p>
</blockquote>

Conclusion</h2>
Building this taught me that "hacking" is often just applied statistics. By analyzing the structure</em> of passwords rather than just guessing blindly, we can reduce the search space by orders of magnitude. The next version of this engine will likely be written in C, but Python proved to be the perfect laboratory for proving the concept.</p>
You can view the full source code on Codeberg</a>.</p>



Demystifying Non-Blocking I/O in C
Unknown — Wed, 21 Jan 2026 00:00:00 +0000
The Problem with Blocking</h2>
When I decided to write a TCP Port Scanner</a> in C, I initially looked at the standard connect()</code> system call. The problem with the default behavior (blocking mode) is that if you try to connect to a firewall that simply drops packets (a "filtered" port), your program hangs. It waits for the OS timeout, which can be anywhere from 30 seconds to several minutes.</p>
For a scanner checking 1,000 ports, that is unacceptable. I needed a way to control the timeout precisely, say, 1 second per port—and keep the application responsive to Ctrl+C</code>.</p>
The Solution: select()</code></h2>
The solution is to set the socket to non-blocking mode</strong> using fcntl</code>. When you call connect()</code> on a non-blocking socket, it returns immediately. Usually, it returns -1</code> with the error EINPROGRESS</code>. This isn't a failure; it just means the TCP handshake is happening in the background.</p>
To wait for that handshake to finish (or fail) with a custom timeout, I used select()</code>.</p>
The Critical Trap: SO_ERROR</code></h3>
Here is where many implementations fail. When select()</code> tells you the socket is "writable," that doesn't necessarily mean the connection succeeded. It just means the handshake is done</em>. It could have been a success (ACK) or a failure (RST).</p>
If you don't check the actual socket error, you will report closed or filtered ports as "Open."</p>
Here is the core logic from my implementation:</p>
// Inside scan_port()...</span></span>
</span>
// Initiate non-blocking connect</span></span>
int</span> res </span>=</span> connect</span>(</span>sock</span>, (</span>struct</span> sockaddr </span>*</span>)</span>&</span>server_addr</span>,</span> sizeof</span>(</span>server_addr</span>));</span></span>
</span>
if</span> (</span>res </span><</span> 0</span> &&</span> errno </span>!=</span> EINPROGRESS</span>) {</span></span>
    close</span>(</span>sock</span>);</span></span>
    return</span> -</span>1</span>;</span></span>
}</span></span>
</span>
// Use select() to wait for writeability with a timeout</span></span>
fd_set writefds</span>;</span></span>
FD_ZERO</span>(</span>&</span>writefds</span>);</span></span>
FD_SET</span>(</span>sock</span>,</span> &</span>writefds</span>);</span></span>
</span>
struct</span> timeval timeout</span>;</span></span>
timeout.tv_sec </span>=</span> timeout_sec</span>;</span></span>
timeout.tv_usec </span>=</span> 0</span>;</span></span>
</span>
int</span> select_result </span>=</span> select</span>(</span>sock </span>+</span> 1</span>,</span> NULL</span>,</span> &</span>writefds</span>,</span> NULL</span>,</span> &</span>timeout</span>);</span></span>
</span>
if</span> (</span>select_result </span>==</span> 0</span>)</span> return</span> 1</span>;</span> // Timeout</span></span>
if</span> (</span>select_result </span><</span> 0</span>)</span> return</span> -</span>2</span>;</span> // Error</span></span>
</span>
// THE CRITICAL STEP: Check SO_ERROR</span></span>
int</span> so_error </span>=</span> 0</span>;</span></span>
socklen_t</span> len </span>= sizeof</span>(</span>so_error</span>);</span></span>
</span>
// If we skip this, we get false positives!</span></span>
if</span> (</span>getsockopt</span>(</span>sock</span>,</span> SOL_SOCKET</span>,</span> SO_ERROR</span>,</span> &</span>so_error</span>,</span> &</span>len</span>)</span> <</span> 0</span>) {</span></span>
    close</span>(</span>sock</span>);</span></span>
    return</span> -</span>2</span>;</span></span>
}</span></span>
</span>
// If so_error is 0, the port is truly open.</span></span>
return</span> (</span>so_error </span>==</span> 0</span>)</span> ?</span> 0</span> : -</span>1</span>;</span></span></code></pre>Why this matters:</h3>
Writing this scanner wasn't just about finding ports. It was more about understanding the lifecycle of a TCP connection. By forcing myself to handle EINPROGRESS</code> ad SO_ERROR</code> manually, I gained a much clearer picture of how the OS handles networking than i ever would have using a Python lib.</p>
You can view the full source code on Codeberg</a>.</p>



My Homelab is a Surface Pro 9
Unknown — Sat, 17 Jan 2026 00:00:00 +0000
The Hardware Constraint</h2>
Most homelabs start with a Raspberry Pi cluster or an old desktop tower tucked away in a closet. Mine is a Microsoft Surface Pro 9</strong> (i5-1235U, 8GB RAM).</p>
It served me well as a tablet during high school, but when I moved to ETH, it became my first Linux machine. Now, it runs my entire digital life. Because I only have 8GB of RAM, I can't afford to be wasteful. I can't just spin up a separate database container for every single service. I needed a "converged" architecture.</p>
The Architecture</h2>
I use Docker Compose</strong> to orchestrate everything. The core philosophy is Shared Resources</strong>:</p>

Reverse Proxy:</strong> Caddy</a> handles SSL and ingress automation.</li>
Database:</strong> A single PostgreSQL 16 instance acts as the central brain, serving Vikunja, OwnCloud, and Linkwarden simultaneously.</li>
Cache:</strong> A single Redis instance shared across services.</li>
Security:</strong> CrowdSec reading Caddy logs in real-time.</li>
</ul>
The Performance Stats</h2>
The proof is in the numbers. By sharing the database and cache, the efficiency is incredibly high.</p>
</p>
Here is a live snapshot of the memory usage:</p>
~</span> ❯ free -h</span></span>
              total</span>        used        free      shared  buff/cache   available</span></span>
Mem:</span>          7.6Gi       3.3Gi       335Mi        61Mi       4.4Gi       4.3Gi</span></span></code></pre>
I am running 10 active containers and using only 3.3Gi of RAM</strong>, leaving more than half the system resources free for other tasks.</p>
Here is the breakdown by container:</p>
Service</th> Memory Usage</th> Technology</th> Note</th></tr></thead>

Linkwarden</strong></td> ~1.54 GiB</td> Node.js</td> The heaviest container by far (Next.js app).</td></tr>
Uptime Kuma</strong></td> 130 MiB</td> Node.js</td> Monitoring dashboard.</td></tr>
AdGuard Home</strong></td> 115 MiB</td> Go</td> DNS filtering.</td></tr>
OwnCloud</strong></td> 78 MiB</td> PHP/C++</td> File server.</td></tr>
Postgres</strong></td> 77 MiB</strong></td> C</td> Hosting DBs for 3 different apps.</strong></td></tr>
Wallos</strong></td> 49 MiB</td> PHP</td> Finance tracking.</td></tr>
CrowdSec</strong></td> 30 MiB</td> Go</td> Intrusion prevention.</td></tr>
Caddy</strong></td> 25 MiB</td> Go</td> Reverse Proxy.</td></tr>
Vikunja</strong></td> 20 MiB</strong></td> Go</td> To-Do list (backend).</td></tr>
Redis</strong></td> 3 MiB</strong></td> C</td> Shared Cache.</td></tr>
</tbody></table>
Note how lightweight the Go and C-based services are compared to the Node.js ones. A single Postgres instance serving multiple apps for just 77MB is a huge win.</em></p>
The "Split-Horizon" DNS</h2>
One of my main requirements was accessing my services (like tasks.lab.gawindlin.com</code>) seamlessly, whether I am at home or at university.</p>
I achieved this using Split-Horizon DNS</strong> and Tailscale</strong>:</p>

Publicly:</strong> The domains point to my Tailscale IP (or are blocked entirely if not on VPN).</li>
Internally:</strong> I run AdGuard Home</strong> on port 53. It rewrites DNS requests for *.lab.gawindlin.com</code> to the local LAN IP of the Surface Pro.</li>
</ol>
This setup ensures that I never have to toggle Wi-Fi or change URLs. It just works.</p>
Security: Caddy + CrowdSec</h2>
Exposing services is risky, so I automated intrusion prevention. I configured Caddy to output JSON logs, which CrowdSec watches in real-time. If an IP scans too many non-existent URLs (404s) or tries to brute-force a password, CrowdSec bans them at the container level.</p>
Here is how the integration looks in my docker-compose.yml</code>:</p>
services</span>:</span></span>
  # Caddy: The Gateway</span></span>
  caddy</span>:</span></span>
    image</span>:</span> caddy:latest</span></span>
    container_name</span>:</span> caddy</span></span>
    restart</span>:</span> unless-stopped</span></span>
    ports</span>:</span></span>
      -</span> "80:80"</span></span>
      -</span> "443:443"</span></span>
    environment</span>:</span></span>
      -</span> CADDY_INGRESS_NETWORKS=lab_net</span></span>
    networks</span>:</span></span>
      -</span> lab_net</span></span>
    volumes</span>:</span></span>
      -</span> ./Caddyfile:/etc/caddy/Caddyfile</span></span>
      -</span> caddy_logs:/var/log/caddy</span> # Shared volume for logs</span></span>
</span>
  # CrowdSec: The Bouncer</span></span>
  crowdsec</span>:</span></span>
    image</span>:</span> crowdsecurity/crowdsec:latest</span></span>
    container_name</span>:</span> crowdsec</span></span>
    restart</span>:</span> unless-stopped</span></span>
    environment</span>:</span></span>
      Collections</span>:</span> "crowdsecurity/caddy"</span></span>
    volumes</span>:</span></span>
      -</span> /var/run/docker.sock:/var/run/docker.sock:ro</span></span>
      -</span> caddy_logs:/var/log/caddy:ro</span> # Read-only access to logs</span></span>
      -</span> ./crowdsec/acquis.yaml:/etc/crowdsec/acquis.yaml</span></span>
    networks</span>:</span></span>
      -</span> lab_net</span></span>
</span>
volumes</span>:</span></span>
  caddy_logs</span>:</span></span></code></pre>Conclusion</h2>
Running a homelab doesn't require a rack server. With a bit of optimization—sharing your database, using lightweight containers like Caddy, and carefully monitoring resources—you can run a professional-grade infrastructure on a tablet. I will document more about this project here and on my Codeberg</a>.</p>



Hello World: The Terminal is My Home
Unknown — Wed, 14 Jan 2026 00:00:00 +0000
Hello World</h2>
Welcome to gawindlin.com</code>. If you are reading this, you’ve found my corner of the internet.</p>
I built this site to serve as a digital archive, a place to document my work, my studies at ETH Zürich, and the projects that keep me up at night. While the site itself is built with Astro and styled to also function like my beloved Neovim, the content you'll find here going forward will likely dig much deeper than HTML and CSS.</p>
The "Aha" Moment</h2>
For a long time, I built things for the web. I have projects like Screen Savor</a> in my history, and they taught me a lot. But recently, I realized my interests have shifted.</p>
There was a specific day recently that defined this shift for me. I spent the morning reinstalling Arch Linux and configuring Hyprland (because, of course, kernel panic). I spent the afternoon debugging my Homelab infrastructure because an ad-blocker config took down the internet for the whole house. I ended the day grinding through Data Structures and Algorithms assignments for university.</p>
Exhausted but satisfied, I realized: This is it.</strong></p>
I'm not just a developer; I'm a systems enthusiast. I love the grit of low-level programming, the 'logic' of C, and the endless rabbit holes of Linux administration.</p>
What to Expect Here</h2>
This blog won't just be about polished finish lines; it will be about the process. I plan to write about:</p>

Infrastructure & Homelab:</strong> Documenting my setups, like the Kubernetes cluster I help manage for VIS ETHZ</a> or my personal microservices architecture.</li>
Low-Level Learning:</strong> Deep dives into C, POSIX sockets, and things I learned building tools like my TCP Port Scanner</a>.</li>
Cybersecurity:</strong> Write-ups on CTFs (Capture The Flags), security tools I'm building (like sec-suite</code>), and vulnerabilities I'm studying.</li>
Uni Life:</strong> The occasional proof from my studies at ETH that was too interesting (or painful) not to share.</li>
</ul>
Let's Connect</h2>
Whether you are a recruiter, a fellow student, or just someone who stumbled here via Codeberg: welcome.</p>
Feel free to check out my code on Codeberg</a> or browse my CV</a>.</p>

Gabriel Windlin

What a Custom Linux Desktop Actually Looks Like

Building Kiroku-TUI: My First Rust TUI and Why I Needed It

The Stack</h2> ratatui</strong> — TUI framework. Good docs, active maintenance.</li> fuzzy-matcher</strong> — For search. Simple, fast.</li>

What's Next</h2> I use Kiroku every day now. A few things I want to add:</p>

Our Place: Building a Shared Home Across 9,000 Kilometers

Real-Time Presence: The Digital Fridge & Living Room</h2> To make the apartment feel "alive," I used Supabase Realtime</strong> for instant synchronization across the Atlantic.</p>

Deep Dive: What actually happens when you type 'ls'?

De-Magicking AI: Writing a Neural Network in Pure C

C vs Node.js: I fought the Event Loop, and the Loop (almost) won

The Invisible Navigator: Why I Revisit A* in Java

The Only Linux Course You Need: OverTheWire Bandit (0-10)

Levels 0-3: Learning to Walk</h2> The first few levels are about muscle memory: ls</code>, cd</code>, and cat</code>.</p>

Levels 7-10: Text Wrangling</h2> We found the files; now we need to process the text inside</em> them.</p>

Smart Cracking: Teaching Python to 'Guess' Like a Human

The Logic: A "Sliding Window" of Probability</h2> The engine works in two distinct phases: Training</strong> and Generation</strong>.</p>

Demystifying Non-Blocking I/O in C

My Homelab is a Surface Pro 9

Hello World: The Terminal is My Home

Let's Connect</h2> Whether you are a recruiter, a fellow student, or just someone who stumbled here via Codeberg: welcome.</p>

Real-Time Presence: The Digital Fridge & Living Room</h2>
To make the apartment feel "alive," I used Supabase Realtime</strong> for instant synchronization across the Atlantic.</p>

Levels 0-3: Learning to Walk</h2>
The first few levels are about muscle memory: `ls</code>, cd</code>, and cat</code>.</p>`

Levels 7-10: Text Wrangling</h2>
We found the files; now we need to process the text inside</em> them.</p>

The Logic: A "Sliding Window" of Probability</h2>
The engine works in two distinct phases: Training</strong> and Generation</strong>.</p>

Let's Connect</h2>
Whether you are a recruiter, a fellow student, or just someone who stumbled here via Codeberg: welcome.</p>
Feel free to check out my code on Codeberg</a> or browse my CV</a>.</p>