From Clouds to Classics: Revisiting IBM i

As I enjoy a short hiatus to focus on flying and staying current with my pilot duties, somewhere between jobs and between flight lessons, I’ve found myself drawn back to the kind of engineering that first made me fall in love with computing. Not by plan. Just a slow gravitational pull toward clarity.

Lately, that’s meant diving back into IBM i (formerly AS/400), and letting myself rediscover what made it special, and why it still speaks to me.

My first real job in tech was at IBM, doing L2/L3 support for midrange systems. I even spent time at the Rochester Labs, and it left a mark. These were systems designed not for flash or fame, but for mission-critical reliability. The kind of machines that run quietly in the background for decades, and are supposed to. And that well-engineered hardware? The kind of beauty that speaks volumes about the thought behind it. You look at it with the same awe you might reserve for a masterpiece of art.

Rediscovering them now feels almost like rediscovering my Self.

Everything in IBM i is coherent. Predictable. You have physical files (PFs), which are basically your database tables. You have logical files (LFs), which act as views or indexed access paths. And that’s it. No ORM layers. No accidental complexity. Just data, structure, and operations that make sense.

I’ve been exploring commands again, and there’s something almost poetic in hitting F4 and watching the system present every parameter clearly, contextually. You reason about the system, you don’t chase it. And when it comes to reliability? A single SAVSYS can back up your entire operating system and configuration. You can restore it onto another Power machine of any size, and it just works. Like magic … but engineered.

That kind of confidence is rare.

In contrast, today’s Linux ecosystem feels increasingly chaotic. It’s not the kernel, it’s the cultural drift. Too many projects start with a “just pipe this into ‘curl | bash’” attitude. A focus on speed over clarity. Visibility over durability.

And I get it, I’ve been part of that world too. I’ve worked (and still work) on OpenStack, Ceph, Kubernetes … I’ve shipped real systems to production. I’ve written Dockerfiles and Ansible playbooks. I’ve helped design infrastructures for companies that move fast. And I’ve loved -still love- the science, the engineering, the elegance of large systems. The challenge of getting them right. The precision of seeing every piece click into place.

But I miss the old days. Not out of nostalgia, but because I was there when Linux felt like true engineering. When it made sense. I’ve worked at Red Hat, Canonical, and SUSE, and back then, we reasoned things out. Now? You’ll see:

“Run this unsigned, undocumented blob from the internet as root on your production system and… 🤷‍♀️ hope for the best.”

To someone like me, who was raised in environments that prized engineering, that’s a horror show.

So, more and more, I find myself craving a different pace. I want systems that are engineered, not assembled out of shifting pieces. I want to debug without wondering if the root cause is buried under a dozen container layers. I want to know the system will still boot next month, or in five years.

That’s also what’s drawn me to FreeBSD. Like IBM i, it doesn’t scream. It’s consistent. Documented. Predictable. It reminds me of what Linux used to feel like, before the fanboys, before the performance theater, before every tool needed a framework and a plugin ecosystem. But even FreeBSD, I worry, could drift in the same direction, not because of code, but because of mindset. It’s not the tools that ruin ecosystems. It’s the culture around them.

I’m not against innovation. I love clean container images, reproducible builds, and well-written glue code. A single Go binary that does its job without polluting the host? Beautiful. But not when clarity is sacrificed at the altar of speed.

And that’s why I appreciate some engineering practices so much. A Go binary you can copy from one machine to another, and it just works, like an old MS-DOS .exe. IBM i’s equivalent? SAVLIB. You copy programs and data in one clean shot. No 45 install steps. No YAML sacrifices. No hoping the OOM killer stays quiet. It just works by design. And when something works by design, you notice.

Returning to IBM i, and possibly exploring mainframes again, feels meaningful. These systems weren’t built to be trendy. They were built to be right. They prioritize data integrity over speed, uptime over dashboards, durability over hype.

And this rediscovery isn’t just about tech. It’s about rediscovering my true Self. I’ve always had a mind that dives deep, that doesn’t switch contexts easily, that finds peace in structure. I didn’t always have words for that. But looking back, I can see how my best work came from embracing that kind of focus.

Platforms like IBM i, or the mainframe world I’m now curious about, feel aligned with that part of me. It might not be fashionable. But it’s real. And it brings back the sense of joy and meaning I felt when I first started.

I don’t know where this exploration will lead. But I do know it’s worth continuing.

Not for the job market. Not for LinkedIn visibility.
Just to get the fun back in computing. And maybe, in the process, come back to my Self.