Today we're launching a fundraising campaign to sustain and strengthen GNU Guix. Guix is completely independent from any company or institution, we rely on the support of our community to fund the project. If you can, please help sustain Guix by making a donation . DONATE NOW Why we need your support Like many Free Software projects we need financial support because running a project is expensive. We incur costs for development infrastructure, facilitating developer collaboration and supporting the community around the project. As a package manager…
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.
One of the oft-cited reasons people give for not switching to
Guix is that their favourite software
is too outdated, and a look at
Repology shows that they are not wrong.
Now the number of active committers in the Guix project is amazingly small,
and even counting all contributors I am impressed by what these few people
actually achieve. Nevertheless I wondered how I could improve the situation
at least a little bit for packages I am interested in, that is, for the
science team; and the first step is to get an account of what actually
builds and what does not.
So I decided to set up my own little build farm, limited to the packages
in the scope of the science team, using the same technology that powers the
bordeaux build farm.
I call it the Tiny Build Farm for Guix, or TBFG for short,
and this post is the first one in (hopefully) a series of blog posts
about the topic; at the time of starting this series, the TBFG does not
actually exist yet, so wish me luck.
Mes 0.27.1 is a bug-fix release. It represents 53 commits by four
people over one year. This release resurrects supports development
builds with gcc-14 and adds support for using NYACC versions 0.99.0
through 2.02.2.
Recently I changed my ISP, and the new one uses
Carrier-grade NAT,
or CGNAT, by default. While this sounds fancy and professional, it is in
fact even worse than conventional NAT: Not only do all my devices share the
same IPv4, but I share one IPv4 with several other customers!
Apparently I am only assigned a few out of the 65535 ports, and this
assignment may change from day to day, which implies that I cannot connect
from the outside to any of my home devices.
However, I do have a separate IPv4 of my own for a
virtual
machine
at Aquilenet, and it should be
possible to use this as a trampoline to access my home through a virtual
private network.
We are already employing
WireGuard
for one of the
Guix build farms, so it felt like
a natural choice.
Guix provides the wireguard-service-type, which is
documented
with all its options in the manual; but without an explanation of the
general concepts behind the service it is a bit difficult to set up.
The Guix Cookbook
has an
entry
on WireGuard, but it is concerned with kernel modules and connecting to an
existing WireGuard VPN, while my goal was to set one up in the first place.
This turned out to be surprisingly easy.
Bonfire is a new framework to build federated applications that just reached RC1. It is written in Elixir, a nice functional language, and allows communities to create custom flavored Fediverse applications, that can be tailored for their specific needs. I have been in touch with the core team and I'm trying to make the experience of running Bonfire on Guix as smooth as possible.