probably coding something that was supposed to be a small project

low-level software • compilers • games • unix stuff • cars • trains • questionable ideas

I'm Robert. I spend an unreasonable amount of time making software, breaking Linux installs, fixing them again, and turning tiny ideas into projects much larger than they ever needed to be.

Most of my stuff ends up somewhere between systems programming, compilers, UNIX tools and games. I like software that's quick, understandable and doesn't need half the internet installed just to run.

I also like cars and trains. Quite a lot, actually.

If I'm not screwing around with a compiler, shell, operating system or game, there's a decent chance I'm looking at some car I can't afford or reading about a locomotive for absolutely no practical reason.

Things I keep coming back to:

• compilers and programming languages
• command-line tools
• shells and editors
• operating systems
• file systems and search tools
• package managers
• networking
• native game development
• graphics and raylib
• UNIX and UNIX-like systems
• making things faster for no reason other than "because I can"
• joke programs that get way too much engineering put into them

Sometimes I make useful software.

Sometimes I make something completely stupid with an alarming amount of effort.

Both are important.

From Axioms, Order.

A standalone UNIX-like operating system.

It's built around a small practical base, a CLI-first environment and the idea that an OS should actually feel like one coherent system instead of fifty unrelated projects duct-taped together.

File search without having to remember seventeen flags every time.

Fuzzy matching, content filters, interactive searching, natural-language queries and semantic code search.

A low-level recursive filesystem traversal tool written in Zig.

Fast, predictable and intentionally pretty small. It walks directories. It does the job. It does not need an ecosystem.

A terminal text editor inspired by older editor workflows, with some modern safety and convenience stuff added where it actually helps.

My Ruby shell.

Built-ins, history, autosuggestions, scripting features and a bunch of terminal quality-of-life stuff. Basically the result of repeatedly saying "I could probably make my own shell."

A GTK image writer for UNIX and UNIX-like systems.

Mostly exists because writing an ISO to a drive should not require a spiritual journey.

A small, fast HTTP client written in Odin.

An open source block/voxel game.

Because apparently writing systems software wasn't enough of a rabbit hole.

small binaries
native code
fast command-line tools
compilers
weird programming languages
unix-ish software
editors
shells
kernels
games
build systems
things with too many pointers
things with not enough pointers
stuff that probably should not exist

I don't really care about making something sound impressive.

I'd rather it compile quickly, run quickly and be pleasant to actually use.

This changes constantly, but usually some combination of:

• operating systems
• compiler work
• language design
• native ELF tooling
• package managers
• recursive file traversal
• smarter file search
• terminal UX
• raylib games
• networking
• weird old programming languages
• weird new programming languages
• my web chat platform
• Linux
• whatever dumb idea sounded easy at 2 AM

There is a very real chance the project I am working on right now did not exist yesterday.

Yes, I do occasionally look away from a terminal.

I like cars, working on them, learning how they work, comparing engines and drivetrains, and generally staring at machinery that turns fuel into bad financial decisions.

Also trains.

Freight trains, passenger rail, locomotives, old rail equipment, new rail equipment — pretty much the entire giant-steel-machine-moving-on-two-strips-of-metal situation is cool.

Computers, cars and trains are basically the same hobby if you ignore enough details.

• fast is good
• simple is good
• understandable beats clever
• native binaries are nice
• don't add dependencies just because you can
• don't make the user fight the program
• old ideas aren't automatically bad ideas
• finish things
• make the terminal fun again

GitHub: @RobertFlexx
Email: robertflexxgh[at]gmail.com
Discord: @programmingisprogaming

And yes, i use em dashes because they are uniform.

_{less bloat. more software.}