Rust has a useful concept of “features” baked into its packaging tool cargo which allows developers to optionally toggle functionality on and off. In a simple project features are simple, as you would expect. In more complex projects which use cargo workspaces the behavior of features becomes much more complicated and in some cases..surprising!

Storing bytes at scale is never as simple as we lead ourselves to believe. The concept of files, or in the cloud “objects”, is a useful metaphor for an approximation of reality but it’s not actually reality. As I have fallen deeper and deeper into the rabbit hole, my mental model of what is storage really has been challenged at every turn.

I have been using sccache to improve feedback loops with large Rust projects and it has been going okay but it hasn’t been the silver bullet I was hoping for. sccache can be easily dropped into any Rust project as a wrapper around rustc, the Rust compiler, and it will perform caching of intermediate build artifacts. As dependencies are built, their object files are cached, locally or remotely, and can be re-used on future compilations. sccache also supports distributed compilation which can compile those objects on different computers, pulling the object files back for the final result. I had initially hoped that sccache would solve all my compile performance problems, but surprising to nobody, there are some caveats.

For an upcoming hack week I wanted to have some live jam sessions with colleagues on a video call. Mostly I wanted some background music we could listen to while we hacked together, occasionally discussing our work, etc. I don’t normally use Pulseaudio in anger but it seemed like the closest and potentially simplest solution.

Words cannot express how excited I am for the coming margin squeeze on every “AI company” that isn’t Anthropic, OpenAI, Microsoft, or Google. The entire industry is built on an unethical foundation, having illegitimately acquired massive amounts of content from practically everybody. The companies selling “AI Coding Assistants” I am particularly excited to see implode.

The layers of abstraction in most technology stacks has gotten incredibly deep over the last decade. At some point way down there in the depths of most data applications somebody somewhere has to actually read or write bytes to storage. The flexibility of Apache Parquet has me increasingly convinced that it just might be the last data file format I will need.

Large Language Models have made the relationship between software efficiency and environmentalism click for many people in the technology field. The cost of computing matters.

The process of switching to a more electric house, and therefore more renewable, is two parts: remove fossil fuel powered components and remove load. I wrote previously about using a home battery which has really made a big dent in the ability to switch loads towards electricity. I have recently done some more analysis on the humble clothesline.

The oft touted principles of “pragmatic software development” are by and large nonsense. While not unique to software development many people like to choose their dogma and then wield it uncritically when any opportunity arises. “Don’t Repeat Yourself” (DRY)is one of the “principles” that has always irked me.

The Apache Parquet file format has become the de facto standard for large data systems but increasingly I find that most data engineers are not aware of why it has become so popular. The format is interesting especially when taken together with most cloud-based object storage systems, where some design decisions allow for subsecond or millisecond latencies for parquet readers.

The discourse around “AI” has finally started to shift to a very key question: who are the winners and the losers? The fundamental thesis of shoving Large Language Models (LLMs) into everything is that it will increase productivity. Setting aside the question on whether those productivity gains are happening or even possible, the question of who reaps those rewards is starting to become a larger concern by software developers I follow.

I deploy on Friday. I have heard the arguments to the contrary and I still continue to deploy on Friday. The end of the week is as good as any other to deploy! Why wait another two days to realize the value or return-on-investment from the work I have queued up? I feel confident making this judgement call for two important reasons: I am confident in the success of the changes being deployed and I am willing to take ownership for when I’m wrong.

Writing has been a part of my work for a long time, it helps me think and more importantly it helps me share ideas with other developers. Recently a tremendous amount of my time has been spent writing internal design documents, blog posts, and other materials. By the time it has come to personal blogging my words all been spent.

I spend a lot of time looking at and optimizing costs, kind of for anything. I do it as part of my day job, I do it as part of my night job, and of course for my home life as well. Spreadsheets on spreadsheets tracking and analyzing, finding inefficiencies and opportunities for investment. In 2024 an opportunity presented itself to invest in a next generation home battery which I can now unequivocally say is a good investment.

Some recent changes to the primary server in my office left the fans running louder than previously. I do have some noise canceling headphones but I still don’t want to hear the sound of jet fans from the other room, with a little bit of free time I was able to nail down and correct the behavior using ipmitool(1) and magic bytes.

Whenever a system comes offline I try to always make multiple updates at once. When I recently received some new mounting hardware for one of my big FreeBSD servers, I decided to plonk an idle PCI-e device into the chassis while it was out of the rack.

A colleague once told me about their boss whose office door decorated by a single 8x11 piece of paper with “speed wins” scrawled upon it. I didn’t even work for them and I find that motivating. I think about it a lot, particularly when I’m waiting for Rust builds to complete. Speed wins, every second counts, and “why is this so fscking slow!” all run through my mind as units are compiled and linked.

I have recently been on a quest to get more speed from my Rust development environment, and today’s “why is this so fscking slow!” culprit is rust-analyzer.A larger project like delta-rs benefits from IDE-like machinery to help work across a sprawling codebase written in Python and Rust. rust-analyzer helps greatly with that, but it comes with a speed penalty.

Today I launched a new rework of buoyantdata.com thanks to the work of a designer I found in the fediverse! The original “design” of the site was something I had cobbled together with a Jekyll theme I originally ported to Cobalt, but it was always lacking.

Purchasing new hardware to run Linux on used to be so perilous that I would only buy hardware which was at least 6 months out of date. The ecosystem has changed dramatically such that when my Dell XPS experienced a chassis failure, I went to a big box store and came home with a Lenovo Slim 7. I immediately installed a Linux distribution on it and started setting up my new portable workstation without even considering hardware support.