Why Larry Octal Exists

This is my Hello World! example.

Every technical blog needs a first post, and this is mine. No fireworks, no grand manifesto, no promise to “redefine the future of technology” before breakfast. Just a simple beginning.

Larry Octal exists because real technology is rarely as neat as it looks in conference slides, product pages, or freshly generated diagrams. Systems age. Scripts grow teeth. Servers accumulate folklore. Business processes become entangled with that one database field nobody dares rename.

This blog is about that world.

Not a polished theory. Not abstract best practice floating in a vacuum. Real-world technology: the kind that has to be built, broken, fixed, maintained, upgraded, explained, monitored, restored, and occasionally sworn at under one’s breath.

A blog from the engine room

I have spent nearly 50 years working with web systems, VoIP, Linux, DevOps, business software, and the awkward seams between them.

That means I have seen technology from the less glamorous end: the end where things have to keep running.

I have built systems, inherited systems, modernised systems, and repaired systems that were already old enough to have opinions. I have dealt with code that made perfect sense at the time, infrastructure that grew organically because the business did too, and telephony setups where the documentation was either missing, misleading, or living entirely in someone’s head.

That experience shapes how I think about technology.

I care about elegant solutions, but I care more about working ones. I like clean architecture, but I know the business may need the report fixed before anyone can discuss architecture. I enjoy modern tools, but I am not impressed by novelty for its own sake.

Technology is only useful when it survives contact with users, budgets, deadlines, forgotten edge cases, and Monday mornings.

Why start writing now?

Partly because useful lessons are easy to lose.

When you have been solving practical technical problems for a long time, you collect a lot of small, hard-won knowledge. Not all of it fits neatly into documentation. Some of it is pattern recognition. Some of it is knowing when a “simple change” is not simple. Some of it is remembering that the thing everyone wants to replace is still quietly doing three jobs nobody has mentioned.

Writing is a way to slow that down and make it useful.

I also want a place to explore modern tools, especially AI, without pretending they are magic. AI is interesting. It can be useful. It can also be confidently wrong, strangely helpful, and occasionally like working with a very fast junior assistant who has read the manual but never met the customer.

That makes it worth exploring properly.

Not as a silver bullet. Not as a threat to every job ever invented. Just as another tool in the box — powerful in some places, unhelpful in others, and best used by people who still understand the work.

This blog is where I will record those experiments, observations, and lessons.

What I’ll write about

Larry Octal will cover the sort of topics that come up when technology is treated as something practical rather than ornamental.

PHP and legacy modernisation

PHP has powered a lot of the web for a long time. Some of it is tidy, modern, and well-maintained. Some of it is less so.

I am interested in the practical work of modernising legacy systems without pretending they can all be rewritten from scratch. There is a big difference between improving a system and indulging in a heroic rebuild that never ships.

So expect writing about understanding old code, making safe changes, improving structure, reducing risk, and moving systems forward without setting fire to the business.

Linux and DevOps

Linux remains one of the most useful foundations in technology. It is also wonderfully direct. If something is broken, it will usually tell you, although not always in a tone you would describe as friendly.

I will write about DevOps in the practical sense: deployment, automation, configuration, reliability, logs, permissions, services, backups, and all the other things that decide whether software actually works outside a development machine.

Not DevOps as a slogan. DevOps is the ongoing discipline of making systems understandable and repeatable.

VoIP and telephony systems

Telephony is one of those areas where theory and reality can be separated by a surprising amount of crackle.

VoIP systems are fascinating because they sit at the intersection of networking, software, hardware, providers, users, and expectations that were formed in the days when phones were just supposed to work.

I will write about telephony from a hands-on perspective: how systems are put together, maintained, diagnosed, and made dependable enough for real use.

Monitoring and infrastructure

If a system matters, it should be monitored.

That sounds obvious, yet many systems are only monitored by users complaining when something stops working. This is not ideal, although it is a very traditional alerting mechanism.

Good monitoring is not about collecting every possible metric so a dashboard can look impressive. It is about knowing what matters, spotting trouble early, and understanding the normal behaviour of the systems you run.

I will cover infrastructure and monitoring with that in mind: practical visibility, sensible alerts, and the unglamorous work of keeping things healthy.

AI as a practical tool

AI is too useful to ignore and too overhyped to trust blindly.

I am interested in where it genuinely helps: drafting, summarising, coding assistance, exploration, testing ideas, automation, and making repetitive work less painful. I am equally interested in where it falls short, especially when accuracy, context, judgement, or real operational understanding matter.

The aim here will be practical evaluation rather than breathless excitement.

If a tool helps, I will say so. If it produces nonsense with perfect confidence, I will say that too.

Running small technology businesses

Technology does not exist in isolation. It sits inside businesses, budgets, relationships, support calls, invoices, priorities, and the occasional urgent request that begins with “quick question”.

Small technology businesses have their own realities. You need to make good decisions without unlimited time or unlimited people. You need tools that fit the work, not just the trend. You need to balance improvement with delivery, and idealism with cash flow.

I want to write honestly about those trade-offs.

Opinionated, but not imaginary

This blog will be opinionated.

That does not mean loud for the sake of it. It means I will try to say what I actually think, based on experience. Some tools are better than others. Some practices sound good but fail in real settings. Some old technology deserves respect. Some new technology deserves a raised eyebrow until it proves itself.

The important part is grounding.

I am not interested in pretending there is one perfect way to build or run systems. Context matters. People matter. Constraints matter. The right answer for a small business with a long-running system may be very different from the right answer for a greenfield project with a large team.

Technical judgement is not just knowing what is possible. It is knowing what is sensible.

That is the kind of judgment I want to explore here.

A long-term technical journal

Larry Octal is intended to be a thoughtful, long-term technical journal.

Some posts may be practical notes. Some may be reflections on tools or methods. Some may be about old systems, new systems, or the strange middle ground where most real work happens. There may be code. There may be configuration. There may be cautionary tales.

There will probably also be the occasional reminder that “temporary” solutions have a remarkable ability to become permanent fixtures.

Above all, I want the writing to be useful.

Useful to people who maintain systems. Useful to people modernising legacy code. Useful to people running infrastructure, supporting customers, or trying to understand where AI fits into their work without losing their grip on reality.

Follow along

If you like practical, honest technical writing, you are very welcome here.

If you prefer buzzwords, glossy certainty, and diagrams full of arrows pointing at clouds, this may not be the best place for you — although you are still welcome, provided you do not mind the occasional raised eyebrow.

Larry Octal starts here: with real systems, real experience, and the belief that technology is most interesting when it is being made to work.

More soon.