Planet Guix

Creating something new from scratch implies a certain ratio of unpredictable issues (loosely defined in the scope of this post: new errors, regressions, warnings, ... any unexpected behavior one may encounter). Most important, a digital design developer needs to define somehow what he considers to be a project issue, before even thinking about how to react to it. Luckily, in #modernhw a few usual tools are available to ease the process as a whole. Let’s overview some of them.
Here on the electronics digital design side of life, we have mainly three #freesoftware fine tools (among many others) to perform code checking to a large extent: osvvm, cocotb and vunit. They are all compatible with the ghdl compiler, and they are all available from my own #guix electronics channel (cocotb and vunit will hopefully get merged on guix upstream at some point). Each departs from the rest, adopting a different paradigm about how digital design testing should be understood: verification, cosimulation and unit testing are master keywords here.
They are all complementary, so you’ll be able to combine them to test your designs. However, you’ll need to be careful and check twice what you’re doing, as some of their features overlap (random treatment, for example). You’ve been warned.

Guix reveals as a practical means of handling dependencies. However, the amount of information available to start using it may appear as a bit overwhelming for a beginner, letting the feeling of a tool reserved to a reduced community or experts. Far from that. Here you’ll find everything you need to get started with guix, with a light touch on using it for #modernhw.
We will concentrate in the use of #guix as an external package manager on top of a #linux distribution based on #systemd. We’ll let aside using and referring to #guixsystem as a full operating system by itself (which I never used anyway). This way, in the context of #modernhw, we may keep on using our favorite tools, environment and workflow. As an addition, we have everything that guix provides at our disposal, without affecting our local packages configuration: guix acts as an extra layer on top of our current OS, without any interference with it. You’ll have the possibility to install any guix software, remove it afterward or make use of the fancy features guix has to offer, without your host OS ever noticing what’s going on.
All what follows is roughly based on the guix reference manual and the guix cookbook, so refer to them for more on depth explanations. This article is strongly influenced by my personal experience as a daily driver, so next topics are necessarily biased towards my own needs.
There is much more to say about guix, but this is just an introductory crash course, right ?

A lot has happened with respect to the Hurd since our Childhurds and GNU/Hurd Substitutes post. As long as two years ago some of you have been asking for a progress update and although there have been rumours on a new blog post for over a year, we were kind of waiting for the rumoured x86_64 support.

High-speed network interconnects are a key component of supercomputers. The challenge from a software packaging viewpoint is to provide an MPI stack able to get the performance out of that specialized networking hardware. As packagers, our approach has been to provide MPI packages that get the best performance of the underlying interconnect, be it Omni-Path, InfiniBand, or any other type of interconnect.

We are pleased to announce Guix-Jupyter 0.3.0, a long-overdue release of our Guix-powered Jupyter kernel for self-contained and reproducible notebooks.

In a previous post I mentioned the way I use Emacs Org code blocks and the so-called Noweb syntax as a templating mechanism. The idea is to have a template version of a document containing a certain number of placeholders and a separate file to store the placeholders' values. The template and the data file are then fed into a build process that recombines things and produces the final document.

I've been noodling on structural editing for a while now. I'm fully bought into Lisps myself, but most of my friends and coworkers are skeptical, and I think a lot of their skepticism has to do (as usual) with all the parens. One of the points I make frequently is that with Lisp code being written as a nested data structure, the textual representation is just one of many possible representations. But it can be hard to get across what that means without concrete examples.

People from Guix London gave me the chance to describe this process.

Ekaitz Zarraga talks about the mission to achieve a full source bootstrap of the RISC-V architecture on Guix Linux. He introduces RISC-V and what makes it different. Discusses the importance of a full source bootstrap for security and trust in computing. Then talks through the multi-year mission to make it a reality on Guix.

It is specifically convenient using Guix-the-system within a foreign distribution, such as Debian, for development and tests. The package management system can be used on top of the system, but I find it quite interesting to explore the potential of the Guix distribution in the context of virtualized environments. For personal use, that is also the ideal way to avoid breaking your own daily boxes every couple of days with daredevil approaches to personal computing.