Machines should work and think; people should enjoy life.
About · Rabbit holes · Toolbox · Activity · Contact
I'm a developer and systems enthusiast who enjoys turning hardware, operating systems, and rough ideas into practical tools.
I'm most interested in the boundary between software and real devices — where limited resources, protocols, sensors, boot chains, storage, and physical interfaces all matter. I enjoy understanding what happens below the abstraction, but I care just as much about making the result useful, understandable, and pleasant to work with.
- Turning specialized controller boards into useful general-purpose Linux machines.
- Finding capabilities that hardware vendors never exposed to the user.
- Building clean interfaces around low-level tools and awkward workflows.
- Making small devices collect, interpret, and present real-world sensor data.
- Automating repetitive work until it quietly disappears.
- Linux & embedded systems — Debian, OpenWrt, ARM, Zynq/FPGA SoCs, boot and storage, reproducible builds.
- Hardware & low-level work — sensors, board interfaces, UART/I²C/SPI, debugging, and giving specialized hardware a second life.
- Networking & security — protocol analysis, Wi-Fi, diagnostics, and practical security tooling.
- Wearables & mobile — Android and Wear OS, sensor-driven utilities, background services, and device constraints.
- Developer tools & automation — small utilities, desktop tools, scripting, CI/CD, and workflows that remove repetitive work.
- Documentation & UX — because a project is not really finished if nobody else can understand, build, or use it.
- Make it useful before clever.
- Understand the system well enough to simplify it instead of hiding complexity.
- Treat hardware limits and failure modes as design inputs, not annoyances.
- Prefer transparent, inspectable solutions over unnecessary magic.
- Keep builds reproducible and documentation close to the code.
- Leave room for experimentation — the best projects usually teach me something unexpected.
🔧 Open the service hatch — what happens when I meet undocumented hardware?
- Identify the interfaces and major components.
- Observe how the system starts and how its pieces communicate.
- Map the hardware against documentation and datasheets.
- Work out what the original software actually depends on.
- Make the platform do something useful beyond its original purpose.
- Document the path so the next person doesn't have to rediscover everything.
🧪 My highly scientific “is this project interesting?” test
- Does it interact with the real world rather than only abstractions?
- Is there a layer the original manufacturer never expected users to explore?
- Can I make it smaller, cleaner, faster, or more useful?
- Will I learn something that transfers to the next strange device?
- Can another person eventually install it without reading my mind?
If most answers are yes, I'm probably already reading the board documentation.
The snake is eating my real contribution graph. It regenerates automatically.
If it has a processor, some RAM and a serial port, it's probably a computer.