For my home media consumption I use a media server that runs in a small VM with passthru of a GPU for transcoding needs. The files are hosted on my local NAS box, which handles running services like Pinchflat and also holds the digitized copies from my wife’s CD collection and my home photo and family video collection. The NAS exports each of these 3 collections as an NFS share that everyone on the LAN can mount, including the media server VM.
So I am doing a rebuild of my NixOS laptop in order to (supposedly) highly optimize the resulting binary code for my local host. Or, at least, all of the libraries written in C. So doing this was pretty straightforward. Before we can build the optimized code, we need to tell Nix that our system supports this as a feature. So the first thing I enabled in my configuration is:
nix.settings.system-features = [ "gccarch-x86-64-v3" ];
A quick nixos-rebuild switch has me up and going in a few moments, as all it needs to do is
write a new nix.conf file.
TL;DR Just let me download it
I have been trying to come up with a good, reliable way to build executables for Windows from Linux for a long time. One of the longer running problems I have had is that the ground keeps shifting out from under me. Sometimes, you’ve got exactly the set of requirements that you need, and that’s all you want! But, when I have previously used things like the MinGW toolchain from Fedora - I would have had to freeze the exact machine I was building on in order to be able to reproduce the same results as before. But, of course, this is not a feasible thing to do, especially for an open source project that is leveraging CI.
I just got a new Pixel device from the Pixel 9 family. While I enjoy the device so far, I don’t want to talk so much about the device here. One of the first things I did with the device was install GrapheneOS onto it for enhanced privacy and security from the spying eyes of the public corporate overlords who want to harvest data for their advertisers. It’s obviously a great business model for them, but I don’t really want to be part of it any more than I am required to be.
I know picking a shell in Unix is, by no means, a simple thing. People have very strong opinions about the shells that they want to use. Beyond using their favorite terminal program, the shell a developer, engineer, or administrator uses is something that is a highly personal choice. Most of us who have been working with a particular shell for a while have probably developed deeply ingrained habits and personalization choices.
I’ve managed to recently upgrade my image building process for this website, using some of what I have been learning about Nix. For a while while I was first learning to use Nix I thoguht of the language, the packages, and the OS as being one thing. And this did a disservice to both the breadth of what Nix offers as well as the capabilities it offers.
So previously with this site I used a fairly straightforward and manual
process. I installed Hugo on my local machine with
dnf, ran the dev server, and
edited my pages. When I pushed the commits into GitHub, I had a
Containerfile in the repository that would get built with Docker or
Podman, pushing the resulting image to my image
repository. I used a
multi-stage file, first pulling the Hugo image to build the files and
then grabbing the resulting build produts to place them into the
Nginx image.
If you are interested in running multiple versions of the same development language using Nix and Nix Flakes, ride along while I setup a development environment that includes Python 2.7, 3.5-3.12 along with necessary development libraries. I will not be covering installing Nix on your system or the basics of the Nix package system or language. At the link above, you can see and fetch the flake.nix file. Each commit in the repository corresponds to a version of the file in this post.
So I have talked before about what CI actually means. That post was, admittedly, rather dry and academic. I think it’s important to sometimes make the distinction between what is just regular automation and what is strictly CI. When there is automation but no CI it is still very easy for errors to slip into a supposedly stable code base, as not every commit is tested before it is merged to the main. However, with the complexity of modern software, it is pragmatically impossible to separate these two concerns, as CI without automation quickly overwhelms any manual system.
So I’ve been playing around with NixOS on a Raspberry Pi 4 that I have at the house. NixOS seems like a great idea, but getting it onto the Raspberry Pi 4 is something of a beast of a process. So I wanted to document here how I did it. Most of the process is the normal NixOS installation process, with a few tweaks at the very end.
Rather than having a plain Raspberry Pi 4 and writing the SD image provided by the NixOS team to that image, I have my Pi in an [Argon One m.2](some link here) case. That case allows me to mount an m.2 SSD to an RPi4 B device over USB3. They’re pretty slick cases, decent quality, include full size HDMI ports and basic power management, and still allow GPIO header splitouts if you need them for your application. If you are looking for a handy little case that is metal, well built, functions as a heat sync, includes a tiny fan, and gives you the SSD USB3 split out, then I suggest you take a look at this case. They also have a version that does not have the SSD, but still gives you the port split out and is the same well built metal top enclosure.
At work I have been doing CI for nearly 10 years, now. Having been working at Red Hat for the past 6 of those, some of the CI work that I do is available in open source contributions up on Git Hub. I plan to make a series of posts about that work, so I am going to start with this brief discussion of the very idea of CI before I get into working on the particular types of CI that I do.