Looking at the Nivenly Discord, I saw Hachyderm.io was having some HTTP 504 issues indicating some backend service was malfunctioning. This lead to a link of a post-mortem last time this happened. 19:06 @dma status.hachyderm.io updated acknowledging the root cause From blog.hachyderm.io This small snippet from the timeline sparked an urge. It was an urge to do web development for a running service, not just a static site or two—of which this very blog is one.

I’m seeing an influx of people talking about “everyone back to the office!” with responses like “lol, I moved. When should I expect the travel itinerary with accommodations you’ve booked?” I too have moved. I too would respond this way. I too believe if I am able to do my job well remotely, it shouldn’t friggin’ matter if you’ve spent millions of dollars on a state of the art office. Your poor investment is not my problem.

I see a good project README answering the following 3 questions: What does this do? How do I install/use it? What do I need to do/know to make changes? I tend to answer this with a few key sections of a README with some self-evident headings. Doing so, in my case, generally looks something like this: # My Project This is my project. It does cool things and talks to neat people.

Recently I’ve gotten fed up with the breaking changes in Homebrew package manager. After some research, using Nixpkgs seemed like a far more stable option for GNU/Linux tooling on MacOS, albeit with a decent learning curve for configuration. Without going too much further into it Nix is pretty cool. Over the following months, I’d been spending what free time I had tinkering with Nix on MacOS, specifically with Home Manager and nix-darwin.

This seems to be a common topic of conversation, so I figure I should put it on paper (so to speak) what I value as a systems administrator, or “sysadmin.” Keep it simple Ensure it can be reproduced Keep it close to stock Magic is bad No development tools on the server Prefer complexity at compile time over runtime Consume artifacts What does this mean? The fewer moving parts, the easier to diagnose By keeping things simple, reproduceable, and close to their defaults, this sets a sysadmin up for success when things go wrong.

Given the recent news that broke about Chef’s changes to their licensing model (and the associated FAQ), a lot of chaos has ensued and I feel the need to straighten out a few things since I’ve been present for most every public development so far. Here’s a quick overview: Rebranding of products Open source release of Chef Automate Change in licensing, affecting monetization Price increase for commercial licenses Let’s break these down into more consumable pieces.