^ ^                 ^ ^
=(o.o)=  ~byakuren  =(o.o)=
  m m                 m m

Home Directory Layout

My home directory follows a structured, minimalist layout inspired by traditional Unix filesystem hierarchies. Each top-level directory serves a specific purpose, keeping things organised and predictable across different machines.

bin   dta   etc   gdf   imp   lib   not   rnd   src   tmp   vcs

Unique Prefixes for Tab Completion

Every top-level directory starts with a unique letter. This means navigating is as simple as cd followed by a single character and tab—no ambiguity, no waiting for a completion menu.

This extends to files too—anything placed directly in ~ gets a name that doesn’t collide with these prefixes. The result is near-instantaneous navigation without ever needing to type more than two or three characters.

bin — Executables

All of my executables live here, organised by type and architecture.

bin/
├── amd64/    # Compiled binaries for x86-64
├── ln/       # Symlinks to binaries elsewhere
├── ni/       # Non-interactive scripts
├── paths     # Additional $PATH entries
└── sh/       # Shell scripts

• amd64 — Architecture-specific compiled binaries. If my home directory is shared across machines with different architectures, each gets its own subdirectory (e.g., arm64).
• ln — Symlinks to executables installed elsewhere, typically pointing into ~/vcs/. This avoids cluttering system directories while keeping tools accessible.
• ni — Non-interactive commands used as building blocks in larger scripts. These are never typed manually—they’re the plumbing, not the porcelain.
• paths — A plain text file listing additional directories to append to $PATH, such as Go’s bin directory or pip install locations.
• sh — All scripts here are plain text with a shebang (#!). I can always open them in an editor and know exactly what they do.

PATH Order

export PATH="$HOME/bin/sh:$HOME/bin/ln:$HOME/bin/amd64:$PATH"

The order here is deliberate:

1. sh (shell scripts) — Highest priority. If I want to wrap or override a command’s behaviour, I write a script. This lets me intercept any command without modifying the original.
2. ln (symlinks) — These point to repositories in ~/vcs/ and are typically more up-to-date than compiled binaries, since they track the latest checkout.
3. amd64 (compiled binaries) — Lowest priority among my own executables. These are rebuilt less frequently, so they yield to symlinked versions when both exist.

This precedence means I can progressively override commands: a script can wrap a symlinked binary, which can itself shadow a compiled one.

dta — Program Data

A centralised location for programs that store their data in a single directory. Examples include:

• Obsidian vaults
• Go module cache
• MPD databases

This keeps application data out of the home directory root while remaining easy to back up or migrate.

etc — System Directories

etc/
├── audio/
├── desktop/
├── documents/
├── downloads/
├── music/
├── pictures/
├── public/
├── sounds/
├── templates/
└── video/

Common system directories and mount points live here:

• XDG directories — Renamed to start with lowercase letters for consistency (e.g., documents instead of Documents).
• Filesystem mounts — Large ZFS datasets for music and video collections are mounted under etc/ rather than cluttering the home directory root.

gdf — Git Diffs

A directory for storing git diffs (patches). Useful for:

• Saving the state of work-in-progress patches during complex operations
• Maintaining patches that need to be reapplied after upstream updates
• Sharing modifications that aren’t ready for a proper commit

Each .gdf file is a self-contained diff that can be applied with git apply.

imp — Important Files

Sensitive documents and files that warrant extra protection. This directory uses additional encryption beyond the standard home directory encryption.

lib — Library Files

Configuration files and assets that get symlinked into their required locations throughout the system:

• Custom keyboard layouts (.kbd, .xkb)
• System files like /etc/issue and /etc/motd
• Custom bitmap fonts for the console
• RSS feed URL lists

By keeping the canonical versions here, I maintain a single source of truth that can be version-controlled and easily deployed to new systems.

not — Notes

Quick notes and scratch files, used in conjunction with shell scripts. A simple, always-accessible location for jotting things down without ceremony.

rnd — Random

A catch-all for files that don’t fit elsewhere but are worth keeping:

• Command output saved for reference
• Datasets used across multiple programs
• Configuration snippets and experiments
• System state snapshots

The name is deliberately short—it’s where things land when I need them accessible but haven’t decided on a permanent home.

src — Source Code

src/
├── apl/
├── bash/
├── bqn/
├── c/
├── cpp/
├── futhark/
├── j/
├── lean/
├── mercury/
├── prolog/
├── python/
├── sh/
├── uiua/
├── unison/
├── uxn/
└── ...

All code I write lives here, organised first by language, then by project. This structure makes it easy to:

• Find all projects in a particular language
• Keep language-specific tooling and experiments together
• Maintain a clear separation between my code and external repositories

tmp — Temporary Files

A tmpfs mount for ephemeral work:

• Testing command syntax
• Extracting and inspecting archives
• Quick experiments that don’t need to persist

Everything here is understood to be disposable. A reboot clears it completely.

vcs — Version Control Repositories

All cloned repositories live here. When I git clone a project, it goes into ~/vcs/.

The symlinks in ~/bin/ln/ typically point to executables within these repositories, providing a clean separation between “software I use” and “software I wrote.”

Design Philosophy

This layout reflects a few key principles:

1. Predictability — Every file type has a logical home. No hunting for where something might be.
2. Portability — The structure works identically across machines and architectures.
3. Separation of concerns — My code, external code, data, and configuration each have dedicated spaces.
4. Lowercase everything — Avoids case-sensitivity issues and looks cleaner in a terminal.
5. Short names — Three-letter directory names are quick to type and easy to remember.
6. Unique prefixes — Single-character tab completion for every directory.

The result is a home directory that stays clean and navigable, even after years of accumulated work.