Notices by Ludovic Courtès (civodul@toot.aquilenet.fr), page 9

One concrete outcome of FOSDEM + Guix Days: the #Guix Foundation has a brand new web site design!
https://foundation.guix.info/

Kudos to Ricardo for the lightning-flash hacking.

“HIP and #ROCm come to #Guix”
https://hpc.guix.info/blog/2024/01/hip-and-rocm-come-to-guix/

New blog post on the 100+ Guix packages contributed by AMD, our preliminary tests on one the French national supercomputers, and how it can benefit going forward to both AMD and the French and European #HPC environments.

@lanodan A static and out-of-band ‘allowedSignersFile’ is an improvement but it’s insufficient: the set of allowed signers evolves over time and this must be accounted for.

That’s what the method described in this paper is about.

@khinsen @akkartik @glyph

@glyph 💯 on the vacuity of signed commits if all it gives is “Verified” ✔ badges with useless semantics.

I wrote about it and about a solution to actually make use of those commit signatures to authenticate #Git checkouts:
https://doi.org/10.22152/programming-journal.org/2023/7/1

@akkartik @khinsen

It’s wonderful: mastodon.el now automatically resolves URLs to Mastodon posts, such that you can view these posts and interact with them without ever leaving the comfort of Emacs. 👍

@kakafarm I don’t know. A colleague noted that the population writing code presumably doesn’t grow exponentially, so most likely it’ll stop growing at some point (unless LLMs get in the way?).

On the curve @zacchiro showed, exponential growth started in the 1990’s (around the time Internet access became accessible and free software took off).

Anyway, thought-provoking.

Insight from @swheritage reported by @zacchiro: code growth has been exponential for decades, whether you look at it in number of commits or number of unique files.

One might have an intuition for that, but with figures confirming it, it’s astonishing.

Virtual build machines to the rescue of software archaeologists:
https://issues.guix.gnu.org/68677

Not just archaeologists actually: it’s something you need to rebuild packages that include “time traps” (fail to build after some time). It’s relatively rare, but when you need them, you’d rather have a simple way to work around the problem.

#Guix #ReproducibleBuilds #ReproducibleResearch

@bugaevc I’m old enough to have seen the rise and fall of GCJ (Java in GCC), in which Red Hat invested a large number of person-years (and not random persons I should say!).

I wonder if GCC-Rust will have the same fate, which I interpret as failure due to social issues. Rust has developed an anti-copyleft, anti-GNU, arrogant culture (how would one qualify the “RIIR” slogan? the claim on “memory safety”?). That might be enough for GCC-Rust to remain a niche.

@wingo This story of Φ and χ is just… terrible. It looks anecdotal but still an illustration of the kind of elitism and exclusionary behavior we can get from academia.

Wirth’s “Plea for Lean Software” (1995) resonates with me.
https://cr.yp.to/bib/1995/wirth.pdf

The problem is more acute than ever. Sure, there are applications today that couldn’t exist 10 or 20 years ago; and yes, interfaces have improved.

Yet common tasks (messaging, web browsing, document authoring, software development) are not all that different but require much larger amounts of resources.

🧵

I sympathize to some extent with the critique of “our recent penchant for friendly user interaction”, insisting that “ease should be based on an underlying concept that makes the use almost intuitive”.

I have a feeling though that Wirth puts too much blame on GUIs. They sure were a significant part of “bloat”, especially back in 1995. But is it still true for the 1995–2024 time frame?

Also, some of the incentives for “bloat” and disincentives for “lean software design” Wirth describes hold for proprietary software, but not so much for free software.

Yet, free software does suffer from the same problem.

20 years ago I’d run GNU/Linux, X11, Firefox, Emacs, Guile, etc. on my Sun UltraSparc4 (64-bit SPARC!). Would I be able to run modern versions of these things on that machine? I doubt it.

Why is that?

(Linux and Debian dropped SPARC64 years ago anyway.)

All the articles at https://hpc.guix.info/blog/ are now officially under CC-BY-SA/GFDL.

We had made the mistake of not clarifying this from the start; I’m glad this is now fixed after a smooth and surprisingly fast process.

#Guix #HPC #ReproducibleResearch #OpenScience

mcron or micron?

https://www.gnu.org/software/mcron
https://www.gnu.org.ua/software/micron *New!*

(It’s 2024 and “everyone” uses systemd timer units, true, but GNU thrives to give you the best alternative options, just in case⸮)

The 🐑 #Shepherd 0.10.3 is out, whee!
https://lists.gnu.org/archive/html/guix-devel/2024-01/msg00046.html

I donated to @Framasoft yesterday:
https://soutenir.framasoft.org/en/

They’re doing an amazing job at actually improving user autonomy (PeerTube, Mobilizon, etc.), raising awareness about autonomy and privacy, reaching out to non-profits that should care about these issues, and more generally putting empowerment front and center. 👍

One thing I’d like to discuss at the upcoming #Guix Days is infrastructure maintenance and sustainability.
https://libreplanet.org/wiki/Group:Guix/FOSDEM2024

We’ve accumulated a number of valuable services (ci.guix.gnu.org, qa.guix.gnu.org, data.guix.gnu.org to name a few) but maintaining them requires work, commitment, and money.

How can we collectively keep that afloat? How do we adjust the scope of what the project runs?

As an example, @cbaines recently explained that they won’t be able to keep qa.guix and data.guix running and are considering shutting them down:
https://lists.gnu.org/archive/html/guix-devel/2023-12/msg00021.html

To me, this calls for financial and human support, which in turn suggests we need to better organize as a project.

I’m sure we can learn from other projects in the same space—thinking about Debian and NixOS in particular.

Advice and experience reports are welcome!