I've had this hardware (i5-2500k with a capable cooler) for ages now, and I haven't been using it for many years.

It still works though, and I've managed to overclock the processor to 5Ghz.

I haven't got around to measuring the single core performance, though at some point I want to see how it compares to my i7-8700K.

I never thought a saw would be important when plugging in this connector, but it now fits, so I'm pretty happy!

armhf-linux builds are now happening at pace for guix.cbaines.net/ 🎉

There were some problematic derivations, and I had to unblock those manually. There could have been some Guix Build Coordinator bugs involved too though.

I'm excited to see how well this works, mixing native aarch64 hardware and QEMU emulation for aarch64-linux seems to have worked well. For armhf-linux, I'm using a mixture of compatible aarch64 hardware and QEMU on x86_64.

I did it! I merged #Guix code that includes 4- and 6-year old commits, no less, and that have been rebased a number of times.

It's about using G-expressions all the way down, including for packages. Finishing a transition started 6 years ago, yay!

Build Coordinator progress, I made some database schema changes, and the size of the guix.cbaines.net database dropped from ~43GB to ~11.5GB!

When I started writing it, I used natural keys, UUID's for the builds, and /gnu/store/... names to identify derivations. This was fine at small scale, but with lots of builds and derivations, it made for a much bigger database, and slower queries.

This morning on actual things expects you to read:

WARNING: WARNING: (guix-build-coordinator coordinator): imp(guix-build-coordinator datastore sqlite)orte::d imopdurlee d module (fibers) overrides core booivndrinig e`s core binding `'

Whoo, it's pretty rough around the edges, but this is probably the first Build Coordinator agent build on the GNU Hurd!

Guix has made it into Debian Unstable! This means Debian users can use Guix as a "userspace" package manager now! tracker.debian.org/pkg/guix

This is really wonderful! Debian and Guix both care deeply about reproducibility.

This could be a big win for user freedom on both (cotd ...)

Wooo, I wasn't planning to spend this evening debugging cryptsetup hanging on my laptop, but that's what I've been up to.

I probably should be doing something more important than fixing thumbnails for the Gnome Font Viewer in , but that's what I find myself doing...

Running pg_restore seems to be a surefire way of getting what I believe is the controller on my NVMe SDD to heat up a bit...

I should probably buy a big heat sink for it.

I supposedly know some things about computers, but that apparently doesn't include why my computer says pretty much all of the 60GB of swap space is being used 😦

We closed the gap between Stage0 and Mes: the Full Source Bootstrap is near!

The package graph is now rooted in hex0, a #357-byte binary & ASCII-equivalent github.com/oriansj/bootstrap-s

Make your distro !


Show thread

How many inputs does an average derivation have? Around 31 is my guesstimate from the Guix Data Service data.

This sort of chart might show some more nuances though, there's probably some reason why 3, 6, 10 and 25 are quite popular...

I'm starting to wonder how much of my PostgreSQL query performance problem is down to my M.2 SSD running at +95.8C degrees...

I have a theory as to why this worked. I think the database was returning builds in a sensible order, because the derivations are inserted in to the database in a sensible order, each derivation is inserted after it's inputs.

This is rather more luck than judgement, but for now I'm happy to take it. Funnily enough, as some code in the allocator was reversing the order, that meant the performance was quite poor. Reversing the reverse to maintain the apparently good order did the trick :)

Show thread

Wooo! Turns out that adding (reverse ...) in a couple of places was enough to get the Build Coordinator ordering builds in a pretty sensible way.


I'm pretty sure that change meant that suddenly agents were mostly allocated builds that they could actually attempt, rather than ones where the inputs were missing.

Back when I was using and first found out about , I didn't think it was possible or useful to have a package manager without a dependency resolver. I'd literally spent time working on dependency resolver stuff in APT: cbaines.net/projects/gsoc/2011

I'm glad I was wrong though, I think Guix is so much better for not having a dependency resolver run when you try to install packages.

I'm reminded about this by the troubles I see people still trying to use pip for , just use Guix!

Show older

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!