NAME

I got into C after spending some time jumping between programming languages. I started with Python, looked into Go, and then Rust. Eventually, I wanted to get closer to how programs actually work, rather than relying on a language or runtime to handle everything for me. C seemed like a good place to start.

init87 is my first C project. It's mostly small programs, experiments, and things I write to make sense of the language. I'm still learning, so a lot of it comes down to trying something, getting it wrong, and understanding what went wrong.

I'm particularly interested in the relationship between C, memory, and the operating system. That interest is also why I'm learning x86-64 assembly and Linux syscalls alongside C. I want to understand what's happening beneath the code, one layer at a time. Hoping that one day, I will contribute to the Linux Kernel...

• github

I got into x86-64 assembly through pwn.college's Computing 101 course. I wanted to understand what actually happens beneath C: how instructions manipulate registers, how memory is accessed, and how programs interact with the machine.

I'm not an assembly expert yet, but I can read objdump output to a reasonable extent and follow what a compiled program is doing. I'm still learning the details, particularly the relationship between instructions, calling conventions, and the underlying machine code.

My project init88 is where I document and practise that learning. The goal is to get comfortable moving between C code, assembly instructions, and raw machine bytes, building a foundation for debugging and reverse engineering. All thanks to random redditor for suggesting me to learn x86-64.

• pwn.college
• github

I've been daily driving Arch Linux with Hyprland for almost two years. I like knowing what's installed on my system, why it's there, and how the pieces fit together. I'd rather build my own desktop than have a desktop environment make those decisions for me.

My dotfiles project, hyprdots-0, is where I put that philosophy into practice. It brings together Hyprland, Noctalia, and the rest of my desktop configuration, managed with chezmoi. The goal isn't just to make the desktop look good, but to understand and maintain the system behind it. Lua:)

Two years of daily driving Arch has taught me to value control over convenience, minimalism over unnecessary services, and understanding over blindly copying configurations. And, as @david_bombal said, with great power comes great responsibility...

• github

Almost 4 years - it started when I started using linux. Version control for the code, and increasingly for the documentation vault too - it's grown past the point where I can keep it all in my head.

This is the layer between "the C function you called" and "what the kernel actually did." And from a securit point of view - understanding the kernel does a lot good than instead of just guessing the C optimisations. This is usually where the interesting footguns live - open(), read(), fopen() all have a story once you go past the signature and; honestly I do not know all of them - just learning.

I write a lot. Previously in my school days I write in paper, hand printing whole books in my own words and working out 25 notebooks of math problems in calculus; I have not changed in a year - even now I write the kind of reference I wish existed when I was stuck - full signatures, edge cases, errno tables, worked examples, that cross-linked to related functions.

I simply could not resist; I unusually document or write more that what actually is needed - like a writeup; that actually helps when I come back to read my custom C string library -(ah from my future me).