Osinachi Nwagboso: Technical Journal

Productivity: Nix (To be renamed)

2026-10-14T00:00:00+00:00

I enjoy learning and building things, so naturally I got productivity-pilled: Notion, Obsidian, E-Ink tablets. Along the way I fell for heavy metal, game modding and Olympic weightlifting. (Not much carry-over, I know.) But it sparked something. I needed a way to organise my life.

Every tool taught me something. Todoist taught me to run my hobbies as projects. Obsidian’s graph view taught me to think differently about notes and to journal with intent. Notion taught me that information shouldn’t be text alone.

A few months later I needed pro features from five different tools, and I didn’t want to pay £100 a month just to be productive. So I built something that did everything I needed.

Everything is an item#

In Nix, a note, a project, a reading list and a budget are all the same thing: an item with an optional body, properties and children. What changes is how you look at the children. The same tasks can be a list on Monday, a board on Tuesday and a calendar on Friday, with no copying.

A body doesn’t have to be text, either. It can be a canvas for diagrams, or a spreadsheet with real A1 formulas. Notes support Mermaid diagrams, tables, callouts and columns.

Projects, links and journaling#

From Todoist: tasks with due dates, priorities and recurrence, Today and Overdue views, push reminders with quiet hours, automations, and two-way sync with Google Calendar and Outlook.

From Obsidian: [[ links, backlinks, a graph view with a time view, and daily notes that file themselves. There’s a Vim mode, and an Emacs mode, because I’m not a monster.

I also built habit tracking with streaks, and finance tracking with budgets, bank CSV imports and a close-the-month checklist, which is the most adult thing I have ever built.

AI that lives in my notes#

This changed how I use Nix the most. I use AI to manage my notes, summarise my journals and pull insights from my weeks, months and year. Months of daily notes become something I can ask questions of.

I self-host a lot of things, and my journal is the last thing I’d hand to another subscription app. So the AI lives inside Nix, on my server. You bring your own provider: Claude with an Anthropic API key, OpenRouter (including open-weight models), or, for now, a ChatGPT subscription.

The AI is a companion pet that can search, write, reorganise and build structure. Ask for a training log and you get the container, fields and views, and the pets are genuinely good at picking the right view. They also have no special access: every action goes through my permissions, and every plan is shown to me before it runs. Through MCP, any other AI tool can work with my notes under the same rules.

My favourite habit is asking the companion for feedback on its own tool usage: what was awkward and what it would change. An AI using your product all day is a very honest user. [Example: the companion pointed out that it struggled to produce the correct json format for the nix format and was just guessing]

Built for teams, and for building itself#

A collaboration server gives Nix real-time editing with live cursors, plus roles and invitations, all enforced by the database rather than the browser. That makes it a solid home for a small team.

It’s also where I build Nix. My dev notes, plans, decisions and Mermaid architecture diagrams all live in Nix, and through nixctl and MCP, my coding agents read the same docs I do. If something annoys me, it gets fixed, because I’ll hit it again tomorrow.

A playground for platform engineering#

Nix runs on an ARM64 NVIDIA box in my homelab, and it taught me platform engineering properly:

CI builds everything. Multi-arch images, tagged with the full commit SHA. No latest.
Releases are boring on purpose. A drift preview first, migrations as isolated jobs, and a smoke test that checks real exported files. A green health check is not a successful deployment.
Backups are tested. Nightly, verified, encrypted off-site to Cloudflare R2.
Deleting is a skill. I retired OpenSearch, MinIO and a monitoring stack. Every service you run is one you have to back up and secure.

This blog is a note#

You’re reading Nix right now. Any page tree can be published as a static site. My blog, portfolio and the Nix docs are all just notes.

Even the website for the product is written in Nix: https://nix.nixsites.com/

What’s next#

Nix is v0.1, and I want it to be a premium product. Friction irritates me, and in beta I’m the one feeling it most.

First, a cleaner desktop UI. Second, a native mobile app. The PWA’s offline support is my biggest pain point: it only keeps notes I’ve already opened, and the browser decides how long to keep them. I want my whole life available on a train with no signal. I’m deciding between React Native and fully native, with Swift first and Kotlin later.

Android matters for one more reason: my E-Ink tablet runs it. Journaling on E-Ink, synced to my own server, is the setup I wanted when I first got productivity-pilled.

The catch#

Nix is self-hosted and isn’t small yet, and it needs a new name, because Nix is taken by a famous package manager. Suggestions welcome.

It's still rough around the edges and still needs a couple of months before it's the premium product that I'm currently dreaming of but this is a great start and it's already very useful to me.

AI as a layer of abstraction

2026-06-28T00:00:00+00:00

I started developing software when I was about 9 years old and one thing I have always wanted to make is my own programming language. My first attempt was a C style language that made use of XML style tags. This was not by conscious design, I just didn't know how to make a proper parser so I used Regex and the tags made it easier to cheat.

Another difficulty that I faced was handling scopes recursively so I designed the language to support exactly one scope and made all the statements separated by "|" because the parser would see ";" as the end of a statement and the interpreter would just crash.

Additional context: This was just before I started my undergraduate degree.

Fast forward 8 years, I have by computer science degrees and work experience and Claude code. At this point, I also know the features I like from different languages, link Linq from c# or union types from typescript or C. I decided to bring G (Gnosis meaning knowledge) back to life so I did and I got help from the AI and we came up with something beautiful.

Here is a platform to learn GLang: Glang Link

The platform has:

A fully functional language server
A playground where you can play with the language
and lessons because why not

and the backend was written in Glang: Glang Source Code

Conclusion#

This experiment had me thinking about the state of software development because I wrote a fullstack application in a fictional programming language. My gnosis (pun intended) is that all programming languages are fictional and the orchestration of AI could just be another higher layer of abstraction some day and that's okay.

Why Your Jetson Won't Stay Bricked (Probably)

2026-06-17T00:00:00+00:00

I always wondered what WSL (Windows Subsystem for Linux) was actually for.

Why not just use Linux? It always felt like a strange amount of work to avoid buying a cheap ThinkPad, dual booting, or spinning up a VM. I never really saw the point. Then I started working with Jetsons.

For context, we use quite a few of them at work because a lot of what we do involves AI at the edge. Vehicle tracking, image processing, and inference running somewhere that doesn't have the luxury of shoving everything into the cloud. CUDA has always been a bit of a pain in this space. It has improved considerably with CUDA 12, but there are still enough moving parts that cause people pain.

We also work with the Home Office, which means once something has been deployed it doesn't move very quickly. If a system was validated on a particular JetPack release, there is a decent chance it stays there for quite a while. That's how you end up supporting several JetPack versions at the same time instead of simply upgrading everything and forgetting about it.

The version problem nobody mentions#

NVIDIA ties JetPack releases fairly closely to host Ubuntu versions.

JetPack Host Ubuntu 4.x - 18.04, 5.x - 20.04, 6.x - 22.04

That sounds harmless until you're supporting several projects at once.

Without WSL, your options are fairly uninspiring.

Approach	Reality
Dedicated flashing machine	Works, but you've committed an entire system to one purpose.
Multiple partitions	Fine until you're rebooting several times a day.
Several old laptops	Also works, but no one wants a growing pile of Ubuntu machines under their desk.
Virtual machines	Sounds sensible until USB passthrough starts behaving unpredictably halfway through a flash.
WSL	Open an 18.04 shell, do the flash, close it, then move to 20.04 or 22.04 when needed. Or even have all devices being flashed at the same time (Don't forget to use Usbpid to make the USB visible to WSL.)

You usually don't touch flash.sh #

Another thing that surprised me when I started was how little people actually interact with flash.sh.

SDK Manager does most of the work.

It downloads the BSP.
It prepares the root filesystem.
It invokes the flashing tools.

Most people probably never even notice the underlying commands.

That changes fairly quickly once custom hardware appears.

A lot of carrier board vendors provide their own patches, device trees, kernel tweaks, pin mux settings, or partition layouts. At some point someone sends you a tarball and a PDF containing instructions that basically translate to:

Please read this carefully because support does not want to talk to you tomorrow.

That patch file isn't optional.

Skip it, apply the wrong one, or patch the wrong L4T version and you suddenly have a £3,000 box that doesn't boot.

The really frustrating bit is that it often doesn't tell you why it doesn't boot because the thing that would normally explain what is wrong was part of the thing you forgot to patch.

Jetsons are harder to brick than people think#

The good news is that Jetsons are surprisingly forgiving.Most failed flashes aren't actually bricks. They just end up back in recovery mode waiting for another attempt.

The failure modes usually look something like this.

What went wrong?	Can recovery mode save it?
Corrupted root filesystem	Yes
Wrong device tree	Yes
Half written bootloader	Yes
Bad kernel image	Yes
Incorrect partition layout	Usually
Burned security fuses	No

Force Recovery Mode lives in the BootROM. It's part of the silicon itself, not something stored in eMMC, QSPI, or Linux.

Broken root filesystem?
Wrong device tree?
Half written bootloader?
It doesn't really care.

Put the board back into recovery mode and it'll sit there patiently

The takeaway#

WSL finally made sense to me once I stopped thinking about it as "Linux on Windows."

For Jetson development, it's more like having three Ubuntu machines stuffed into one laptop.

That isn't obvious from Microsoft's marketing, and it certainly isn't obvious from NVIDIA's documentation.

It's just one of those things you eventually appreciate after flashing your fifth board on a Tuesday afternoon and noticing that you haven't rebooted your workstation once.

The admin panel has no password

2026-04-30T00:00:00+00:00

I've been building this site as a creative outlet, a place to ship something for myself and stretch into web design a bit more. I'm a backend developer in my day job, so getting properly hands-on with React and Svelte has been a nice change of pace (a topic for another day). The previous post covered how it gets deployed onto my K3s cluster. This one is about a smaller decision I made along the way.

The management side of the site has no password.

That sentence reads worse than it is. I didn't replace authentication with nothing. I replaced it with passkeys. There's still a strong cryptographic check between me and the admin interface, it just isn't a string I have to remember. The more I sat with the decision, the more it became a useful lens on a question I don't think we ask often enough: when is a password actually doing security work, and when is it just there because we expect it to be?

Where passwords start to be theatre#

Passwords are the default for good reasons. They're universally understood, work on any device, and are easy to provision. For a system with many users and varied threat models, a password backed by a manager and a second factor is a sensible floor.

But passwords carry failure modes that have nothing to do with how strong the password itself is. They get phished. They get reused. They get leaked in breaches of unrelated services and sprayed at every login form on the internet. A password on a single-user admin panel, defended only by "I am the only one who knows it," is doing less work than it appears to be. The strength of that control isn't really the password. It's the obscurity of the URL plus my personal vigilance, and neither belongs in a threat model with a straight face.

What passkeys change#

Passkeys are a different shape of control. The private key never leaves my device. The challenge is bound to the origin, so a phishing site can't replay it against the real one. There's no shared secret sitting in a database to leak. And the UX is better than a password: Touch ID and I'm in.

For a single-user admin interface, this is a near-perfect fit. The threat I actually care about is someone on the internet reaching my admin panel, and passkeys make that materially harder than a password would while removing phishing almost entirely.

The obvious caveat: passkeys are tied to devices, so you need a recovery story. I use 1Password for sync, which keeps them portable across the machines I actually use.

So when is a password the right call?#

I don't want to land on "passwords are bad." That's the wrong takeaway. A password is a tool with a specific shape, and you pick it when the shape fits.

It fits when you have many users on heterogeneous devices, when you can't guarantee passkey support, or when you need a credential that can be handed off out-of-band. It's theatre when it's the only control on a high-value surface, when users will inevitably reuse it, or when something stronger (passkeys, mTLS, a network boundary, SSO) is genuinely available and you're defaulting to a password out of habit.

The actual lesson#

My decision wasn't "skip the password because it's annoying." It was "the threat I'm defending against is internet-scale credential abuse, and there's a control that handles that better than a password does." The fact that it's also more pleasant is a bonus, not the justification.

Hardening systems is mostly about being honest about what each control does. A password you can't be bothered to remember isn't hardening anything. It's just a worse version of the control you'd pick if you were thinking clearly.

Kubernetes made my life easier

2026-04-26T00:00:00+00:00

I've started taking my personal projects more seriously, which means I've been doing a lot more deployment than I used to.

For a while, the workflow was simple: write a docker-compose.yml, push it to my VPS, deploy through Portainer. Fine on paper. In practice, every deployment was a frenzy. SSL certificates misbehaved. One service would come up while another silently failed. I'd forget which compose flag I needed this time. No matter how often I did it, something was always slightly broken, and the fix was always slightly different from last time.

Eventually I came across k3s: a lightweight Kubernetes distribution that ships as a single binary.

The detour that pushed me over the edge#

I was originally going to deploy my new portfolio to Vercel. Then I hit the limit: 11 serverless functions per project on the free tier. The portfolio itself is simple, but I wanted a blog attached for technical writeups, and that pushed me over. The next tier was £20 a month.

I already pay £10 a month for a VPS that was sitting mostly idle. So I stopped renting someone else's abstraction and ran my own.

The stack#

The portfolio is straightforward, but the blog adds a few moving parts:

MinIO for S3-compatible object storage (blog images, assets)
MongoDB for blog content
Express.js API
React frontend

Under docker-compose, that's four services wired together imperatively, plus a reverse proxy, plus whatever I cobble together for TLS. Under k3s, it's four manifests. Traefik handles ingress out of the box. cert-manager handles SSL declaratively. I describe what I want; the cluster makes it true.

That's the shift. Compose tells the machine what to do. Kubernetes tells it what should be true. When something drifts, the cluster pulls it back. When I redeploy, I'm not hoping the previous state cleaned up properly. I'm declaring the new one.

How it actually went#

Smoothly. I deployed the whole thing from my laptop with kubectl, pointed at the cluster on my VPS. Certificates issued themselves through cert-manager and Let's Encrypt. No frenzy.

The first deploy took longer than a compose file would have. Every deploy since has been faster, more predictable, and easier to reason about.

Why this matters for solo devs#

The pitch for Kubernetes is almost always about scale: surviving a Hacker News hug of death, autoscaling across regions, surviving node failures at 3am. None of that applies to me. I have one VPS and not many users.

What I got instead:

Declarative management. Cluster state lives in a Git repo. Everything is version-controlled.
Quick deployments. kubectl apply -f and walk away.
Consistent output. The cluster converges to what the manifests say. No more "works on my VPS."

Kubernetes isn't just about scale. For a solo dev, it's about not having to remember things. The cluster remembers for you.