Time to ditch Wordpress


Mar 12 2022

Fighting blog software is tiring.

After some serious consideration, I've decided to roll my own software for this site. Why? Wordpress is a fairly massive security liability, and I'd like to avoid the ongoing maintenance effort (or cost of hosted service). Worse, I've found that each new version focusing more on being a full-fledged CMS and less on simple blogging. And - yet worse - I'd like to nuke MySQL / MariaDB as a "thing" on this server.

My original blog was a simple M4 macro and Makefile for a static site. This removed the ability to have comments, but at the time, I was utilizing a static hosting service anyway (no databases!). Management was really darn easy in this case, outside of the gnarly aspect of updates.

Eventually, I'd like to introduce a new/custom BBS style piece of software to run this site - complete with comments, mailbox, and user features. Right now though, I have scant time to actually maintain this thing, and I'd like to "simplify" my tech life management into something that's easy to work with. The original blog will remain available for some time under the /blog directory (to maintain links) - while I work on conversion.

If you're curious to see the (REALLY HACKY!) software stack used for this blog, I'm hosting it on github. Blog entries are simple markdown file with a side-load JSON file to specify all the meta data. A compile python script scans for files, builds an indexes, and poops out some static HTML.

Boom. Done. Simple is better.

Wyrm: Chipping Away at ELF


Jul 12 2021

Since Wyrm is utilizing a bootstrapped Scheme variant, building data structures and writing files is surprisingly difficult. Scheme provides the ability to express almost any construct, but without standard libraries every tiny detail most be determined.

The "actual" Wyrm system will eventually provide low level data structures and type support. Any construct utilized by "Mini Scheme" will require duplication between both the Wyrm Scheme implementation, and the "generic" Scheme based system. Writing the ELF decoder, the first obvious challenge to address is some form of structured data support. Normal scheme applications might use a SRFI-1 based "associative list". Ideally, Wyrm will implement an associative container with "better performance", but for now, utilizing a wrapped associative list works well. Given the newly defined "dictionary" type, the next hurdle is implementing basic support for serializing structures. For this, a new 'encoding' structure is created. With a defined dictionary type and serialization structure, implementing basic support for the primary ELF file header is simple.

So far, basic Test Driven Development ("TDD") practice has allowed development of substantial infrastructure without gnarly scaffolding. The current 'Wyrm' program remains a simple "Hello World" display, but substantial support for ELF and "Wyrm" common scheme library support is present.

The huge challenge remains focus. Even basic decisions get easily bogged down if considering all the possible angles of a full toolchain ecosystem. Worse, there's nearly infinite complexity possible if attempting to expand to a more modern feature set. But, without the massive set of refactoring and "intelligent" coding tools, any added functionality becomes massively distracting. A worthwhile detour might include integrating Visual Studio Code for improving quick reference documentation.

Introducing Wyrm


Jun 29 2021

For a long time, I've maintained various iterations of low level operating system logic or programming language interpreters. The earliest iterations focused on recreating QBasic and DOS. Newer iterations focused on various technology stack ideas (the last being microkernel and exokernel based approaches). The only time my software stack ever ventured out to be seen by others was... as sample code for a job interview.

I'll be covering this project on the podcast - but, before adding the glitz to the idea, I find myself wanting to sit and write about the idea. Starting with the why and for and what.

I'd be lying if I didn't admit to a strong desire to build "the next thing". And - I'd be lying to myself if I argued Wyrm had any hope of being the next thing. Instead, the mission of Wyrm is simple: a playground for OS and programming language conceptual development. My hope is to build upon (or create) some framework similar to the hello world staples provided at the OSDev Wik. Instead of duplicating Unix and C, my intent for Wyrm is to explore the history of Amiga, Newton, and LISP machines. And, of course, duplicate Unix and C at some point.

I do not plan on supporting many hardware platforms - only the ARM, and likely only one or two available single board computers. I'm considering the Raspberry Pi 4, Asus TinkerBoard, and a QEmu Aarch64 machine for starters. This does presuppose that I manage to get the language itself into a workable state. As I don't have a lot of time to dedicate toward the project, I suspect progress will be slow and be redirected to other ARM (or Risc-V) cores as time goes on.

I'm starting with a "blank slate" for this project. My goal will be to cover the fits and starts and pain associated with birthing an Operating System from scratch. There's multiple toy OS projects out there - and multiple "real" projects - but developers tend to "wait" until some mythical "beta" period. Realistically, I don't see myself having the time to hit such a milestone quickly. (Especially starting from the ground-up). That said, I've built many toy interpreters and kernels - so I suspect there'll be something that appears at some point. From experience, a bootable "hardware" ARM kernel is a few weekends worth of effort. That said, my free weekends are few...

elfenix/wyrm: OS and Language Playround (github.com)