Planet Guix

Yesterday, I got access to a virtual machine from my university for a school project. Great! The only catch: it was only accessible in the internal network via an obscure VPN protocol.

Guile Load Path is a place (or more precisely places), where Guile looks for the source code. This is the first thing one needs to set correctly to work on a Guile Scheme project. It makes Guile aware both of your own modules and external dependencies. For more details refer to Load Paths page in Guile Reference Manual. This guide will focus on getting and setting the right values for it and discussing different approaches to do so.

A blog post documented an elegant way to configure screenshots in wayland using grim and grimshot. After moving my sway config to use the GUIX sway-service to generate the config file Iost my configured screenshot bindings.

In our efforts to create a Tiny Build Farm for Guix, that is supposed to report on the status of the packages assigned to the science team, so far we have seen how to set up the required infrastructure. On a dedicated machine with Guix as its operating system, we have added several Shepherd services: the Guix Build Coordinator together with a build agent; and the web server part of the BFFE, which enables us to follow the activity of the builders. For performance reasons, we have renounced at installing an instance of the Guix Data Service, and opt instead for talking to the instance operated by the Guix project at https://data.guix.gnu.org/, which continually evaluates the Guix master branch and creates derivations for all packages in the distribution. The next step is to explore how to programmatically talk to the remote data server from a Guile script, how to extract derivations we are interested in, and how to submit them for building to our instance of the build coordinator.

The Shepherd got a new hut! The previous one was showing its age and started to feel more like a Continuously Vanishing Shed.

This fictional story begins more than 10 years ago. I was a student at technical university and was confused by how outdated some of the programming-related courses are. I was checking out a few first lections and usually skipping the rest of them (except a couple courses that were fun and uptodate). In my spare time I was tinkering on gentoo linux, cybersecurity and competitive programming (codeforces, ACM ICPC, etc). I wanted to start working ASAP, so that I could finally get to the most interesting part, but man, how wrong I was...

Free Software for Correctness;
Correctness for Free Software.

A cloud-init service for Guix is still a work in progress. Meanwhile, here's how you can deploy Guix on DigitalOcean right away.

Complex end-to-end tests in development repositories involving packages written in several languages are a chore to describe and maintain. Often, the only recourse is to pull in pre-built binaries or haul around heavy Docker images. Could there be a better way? Could it be Guix (spoiler alert: yes!)?

In the last few months, I have installed and upgraded my second preferred GNU/Linux system, GNU Guix, on multiple boxes. Regarding that system, I have already written a few introductory posts in the recent past. This is an update about my experiences as a user and developer. I still think Guix is a giant step forward in packaging and management, in comparison with Debian and other distributions, for elegance and inner coherence.