Here are some notes about installing Guix SD onto a new system from an existing configuration. We necessarily need to discuss disk preparation and partitioning. Additionally, we discuss from the perspective of existing configurations. I planned to write this back in 2022, after initially switching from NixOS to Guix. I hesitated at the time since such a post would not have any additional value to people otherwise installing Guix. However, going through the process again, I feel there are some comments to capture that may be beneficial to others venturing down this path. I will save the discussion between NixOS and Guix for another time. For now, let's settle on "scheme is more better."

We can easily identify mail servers with MX records. Given only a server name for a particular organization, we can passively fingerprint the email server with a simple DNS query.

Notebooks represent an important improvement for interactive and iterative research. However, they tend to lack portability, reproducibility, and repeatability. In this post, I want to explore the iterations of using Org mode notebooks combined with other tools to develop a (hopefully) portable, reproducible, and repeatable notebook for software engineering experiments. While the focus remains narrowed to software engineering, the tools and techniques described should be applicable to any study requiring these properties.

Here are some terrible plots that tell little about data, very little.

Here's a fun animation of how variables relate to each other within a single method using symbolic states.

Org-Mode is a great way to store TODO items, store notes, and keep track of projects. However, possibly due to ignorance of what is available, getting a concrete high-level view of a project is difficult. There are numerous different visualizations that can be created to see the state of a project. Each answers a specific question, none are entirely complete. Today, I have worked out a mechanism to generate Gantt Charts using dynamic blocks for a specific project tree. In followup posts, I may work out some other visualizations.

Once again, it is time to announce a new GPG key. This document is signed with the old and new key to establish authenticity. However, I forgot the password for the master key, so I cannot certify the new key with the old key. Please use the new key.

Debugging Java programs in Emacs has been a goal and overall feature I have wanted for some time. However, every time I've reached for it, dap-java-debug demonstrated an unbearably slow startup. So much so, that it was often faster and more productive to launch IntelliJ, fight Nix and IntelliJ to load the project correctly, and launch the debugger from IntelliJ.

No more. The pain is gone, forced on by fighting IntelliJ to load one too many times.

tl;dr: self-inflicted pain is a strange way to deeply learn.

When reviewing code, it's often necessary to pull the changes under review. There are ad-hoc ways of doing this. But there are also more automatic ways as well. In this post, we discuss the more automatic approaches for GitHub and GitLab. Other forges may have the ability to use this trick, we discuss how to discover the remote references, if they are available.

There are many blog posts which extol the foundations of writing good, communicative commit messages. These same posts, however, tend to otherwise ignore the question of granularity. In this post, I attempt an answer to granularity. The answer is, of course, it depends.

Another brief digression into organizing source code and projects. Described here is my current ideal, subject to change, that has evolved over the years of being a student, a professional, a contractor, and now a student again.

Small tangent into the basic, how to organize research papers and related artifacts. I have a few ideas for how to best handle this, but nothing concrete I can point to that I'm satisfied with.

Is this a useless divergence into tool sharpening and small optimizations for little gain? Or is this a worthwhile venture to get right early on that pays off in the long term?

"Yesterday, you said tomorrow." Entering the first week of being a full-time graduate assistant, I want to start a more earnest attempt to share more of the experience and the journey. I've always maintained that the journey itself is the worthier part, the ends only a different way to spell "beginning".

In a previous post, I discussed a new static site generation process being used for this blog. More recently, I discussed moving and hosting in AWS Now, I want to briefly discuss how it's now, finally, being auto deployed via Git and AWS Code Build.

There are many posts already out about how to host static sites in S3 and CloudFront. However, I would like to add to the discussion a small contribution of how to do this by creating the resources in CloudFormation, and specifically, how to ensure all content is served via CloudFront and is strictly not available via S3.

Using AWS CloudFormation to configure AWS CloudWatch Events to target ECS is not as well documented as it should be. Here, we walk-through a highly specific use case where the documentation was not here to help, how the solution was found, and possibly some insight when facing similar issues in the future.

In a previous post, I made the fecicious call out to use the source.

A brief overview (read instructions) on setting up a new NixOS system with LVM on LUKS on md. We go through drive preparation, basic NixOS installation instructions, and slight modifications to the instructions for installing a new system from configuration.

NixOS is a new kind of GNU/Linux distribution, borrowing the ideas of functional programming languages to bring about a revolution of how we think about operating systems and software development.

For a few years, I've been using Hugo for blog generation. Recently, I've decided I wanted to take static site generation into a different direction. Specifically, I wanted to use a different source markup and I wanted to write my own tool set for generating the actual HTML.

Configuring conky to display a count and symbol of new mail turned out to be more tricky than I had originally anticipated. This small post quickly explores the issues and my own misunderstandings that led to a working conky configuration and a better understanding of maildir.

Today I'm announcing my GPG transition from my old, and now expired, GPG key: DAEE96513758BF6337F71E491066BA71A5F56C58 and 8FCAF4F0CBB0BB9C590C8ED11CFA8A9CD949D956 to a new master key 932F3E8E1C0F4A9895D7B8B8B0CAA28A02958308. The old key will remain vaild for a little while longer, but I prefer all future correspondence to be addressed to my new key.

Previously, in Git in Reverse, we learned about Git and how it internally stores information. Namely, we went over the "loose" object format that Git uses for storage. However, in the last post, we did not discuss how Git uses another storage format to more compactly store files, changes, and ultimately objects. In this post we will discuss packfiles and how Git uses these primarily for using less bandwidth and, only secondarily, using less storage space for storing repository contents.

In this post, we will go through the steps to get coreboot compiled and installed on a Lenovo x230 laptop. This is a somewhat lengthy and involved process that is not for the faint of heart. It is very possible to ruin or otherwise brick your laptop performing these steps improperly or even properly! You have been warned.

One of the untold benefits of having a runtime is the ability for that runtime to enable loading and unloading code while the runtime is active. Since the runtime is itself, essentially, a virtual machine with its own operating system and process scheduling, it has the ability to start and stop, load and unload processes and code similar to how "real" operating systems do.

We all make mistakes. They are inevitable. We must accept that we make them and move on. But making mistakes in Git seems to be overly complex to resolve and most will simply result to cloning anew and copying the working tree (or some subset) and moving on. This, to me, however, seems like a waste of bandwidth as most issues resulting in broken history are in fact quite easy to resolve, especially so once the necessary tools are known.

Developing Elixir/OTP applications is an enlightening, mind-boggling, and ultimately enjoyable experience. There are so many features of the language that change the very way we as developers think about concurrency and program structure. From writing pure functional code, to using message passing to coordinate complex systems, it is one of the best languages for the SMP revolution that has been slowly boiling under our feet.

It is certainly counter-intuitive to learn to drive by first going backwards, so why learn how to use Git in reverse? The short answer is: knowing the internals of Git should make the commands and workflows of Git more accessible and understandable.

There's a certain art to editing hunks, seemingly arcane. Hunks are blocks of changes typically found in unified diff patch files, or, more commonly today, found in Git patches.

Many Vim users may have, accidentally or not, discovered the dot (.) command in Vim. It's a main stay for a lot of Vim users and is clearly one of those actions that should be in more editors. Except when it is the wrong action for the job.

This page is dedicated to general discussion of distributed systems, references to general overviews and the like. Distributed systems are difficult and even the well established ones aren't bulletproof. How can we make this better? As SysAdmins? As Developers? First we can attempt to understand some of the issues related to designing and implementing distributed systems. Then we can throw all that out and figure out what really happens to distributed systems.

This is the start of a series of posts about better Vim usage. It's yet to be determined how often and how frequent this will run, but expect more than just this first post.

This is the last post in the series on real-time systems. In the first post we discussed Apache Storm and Apache Kafka. In the second post we discussed Apache Spark (Streaming). In both posts we examined a small Twitter Sentiment Analysis program. Today, we will be reviewing both systems: how they compare and how they contrast.

This is the second post in a series on real-time systems tangential to the Hadoop ecosystem. Last time, we talked about Apache Kafka and Apache Storm for use in a real-time processing engine. Today, we will be exploring Apache Spark (Streaming) as part of a real-time processing engine.

The following post is one in the series of real-time systems tangential to the Hadoop ecosystem. First, exploring both Apache Storm and Apache Kafka as a part of a real-time processing engine. These two systems work together very well and make for an easy development experience while still being very performant.