Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")
Hello, I hope it's ok I'm replying to this email as a follow-up to decreasing the cognitive overhead for new users. I'm also brand new to the Guix community and ecosystem. I wanted to share a perspective from a user on a Lemmy instance who wrote why the Guix ecosystem was not friendly enough to meet them where they were, a person in their early twenties. I'd like to suggest approach their criticism with compassion and open-mindedness. @velox_vulnus writes at https://lemmy.ml/comment/4625080 > I don’t like the vibe of ageism against young people that is > associated with GNU. What is also frustrating is their reluctance to > improve their infrastructure. > This reason is kind of terrible, I admit, but they could choose to > move over to Matrix over IRC, but they choose to be willingly open to > spam over having a proper, documented chat channel. I am also > reluctant to use my personal mail, for the mailing list. Matrix gives > me that anonymity, without also having to geopardize on participation. > NixOS is on Matrix, and that’s why I like it. I know Matrix isn’t > perfect, but it the better choice between any other messenger. This user could use an email address dedicated to Guix discussion but really I can only agree that sticking to IRC, which requires a lot of effort to keep a history log and more effort to host a bouncer makes contributing to synchronous discussions difficult. I, myself, am only active on the community-run Matrix server and another, less free, channel because the overhead is just too high. > They could choose to remove non-Libre JS from GitLab, Sourcehut or > Gitea, or at least come with a new source hosting platform, but they > choose not to. I also have a hard time with the insistence on the "Old Ways" as somehow more pure, more legitimate than the new. There's some sense of the expression, "You kids get off my lawn!" And the decentralized nature of sending Git patches by email, which I still have not ventured to try, makes it hard to *discover* Guix development in a single place. A user needs to go to any one of the mailing lists, pull the Git repo or browse Savannah or the issue frontend for bugs and new features they might be interested in, and generally have an idea of what they want to be looking for to find it. Discovery by serendipity is missing. When using the mailing list, even figuring out how to reply to the right thread here in Gnus is trying and I'm not even sure if I've done it right: people change the subject line, threads grow so large they become unmanageable; I had to make sure I CC'd the whole list instead of just reply to this mail's author. I still haven't figured out how to stick guix-devel in my Gnus home screen: my starting view is always empty and I have to remember the shortcut to get to the gigantic overview of every Gmane list (this isn't a cry for help). There's more to their post: I encourage folks to check it out. We have the FOSS technology to tackle a lot of these critiques and bring in a whole new wave of contributors. We have fully open Git forges and modern messaging protocols to make a brand new developer-friendly Guix a reality.
Improving cgroups for fun and Kubernetes
Hello, Guix!
This is my second posting to the mailing list but the first using Gnus
and smtmpmail. If I've formatted anything poorly, don't hesitate to let
me know.
I've been spending a silly amount of time trying to get a local flavor
of Kubernetes running on Guix System. I wanted to share my experience
and also solicit feedback from Guix's developers on how to improve the
cgroups implementation such that those who follow me will have an easier
time of it.
I wish to start by stating that I am largely a Linux enthusiast. Most of
my knowledge of cgroups I owe to reading over the last two weeks.
If I state something as true and I've gotten it wrong, please don't
hesitate to correct me (kindly). With that, here come the statements as
I understand them to be true.
Most flavors of local Kubernetes are expecting systemd, which presents
some unusual challenges for Guix System users, especially when using
Podman rootlessly to run a local Kubernetes cluster, which is my use-case.
As I understand it, systemd creates user "slices", which kind and
minikube then map cgroups to. Patch 64260 added support for cgroups v2,
a necessary requirement for Podman to run rootless containers and
rootless Kubernetes clusters. However, because we don't make use of
systemd and therefore assigned user slices, our /sys/fs/cgroups looks
like this:
ls -lah /sys/fs/cgroup/
total 0
dr-xr-xr-x 7 root root 0 Sep 24 13:09 .
drwxr-xr-x 8 root root 0 Sep 24 13:09 ..
drwxr-xr-x 2 root root 0 Sep 24 13:09 c1
drwxr-xr-x 2 root root 0 Sep 24 13:09 c2
drwxr-xr-x 2 root root 0 Sep 24 16:26 c3
drwxr-xr-x 2 root root 0 Sep 24 16:26 c4
-r--r--r-- 1 root root 0 Sep 24 13:09 cgroup.controllers
-rw-r--r-- 1 root root 0 Sep 24 18:07 cgroup.max.depth
-rw-r--r-- 1 root root 0 Sep 24 18:07 cgroup.max.descendants
-rw-r--r-- 1 root root 0 Sep 24 18:07 cgroup.pressure
-rw-r--r-- 1 root root 0 Sep 24 13:09 cgroup.procs
-r--r--r-- 1 root root 0 Sep 24 18:07 cgroup.stat
-rw-r--r-- 1 root root 0 Sep 24 18:06 cgroup.subtree_control
-rw-r--r-- 1 root root 0 Sep 24 18:07 cgroup.threads
-rw-r--r-- 1 root root 0 Sep 24 18:07 cpu.pressure
-r--r--r-- 1 root root 0 Sep 24 18:07 cpuset.cpus.effective
-r--r--r-- 1 root root 0 Sep 24 18:07 cpuset.mems.effective
-r--r--r-- 1 root root 0 Sep 24 18:07 cpu.stat
dr-xr-xr-x 2 root root 0 Sep 24 13:09 elogind
-rw-r--r-- 1 root root 0 Sep 24 18:07 io.cost.model
-rw-r--r-- 1 root root 0 Sep 24 18:07 io.cost.qos
-rw-r--r-- 1 root root 0 Sep 24 18:07 io.pressure
-rw-r--r-- 1 root root 0 Sep 24 18:07 io.prio.class
-r--r--r-- 1 root root 0 Sep 24 18:07 io.stat
-r--r--r-- 1 root root 0 Sep 24 18:07 memory.numa_stat
-rw-r--r-- 1 root root 0 Sep 24 18:07 memory.pressure
--w--- 1 root root 0 Sep 24 18:07 memory.reclaim
-r--r--r-- 1 root root 0 Sep 24 18:07 memory.stat
-r--r--r-- 1 root root 0 Sep 24 18:07 misc.capacity
You may notice the first problem, which is that the entire tree is owned
by root. kind and minikube don't like this:
2023-09-23T23:33:41.974998799+02:00 Failed to create /init.scope control
group: Permission denied
2023-09-23T23:33:41.974998799+02:00 Failed to allocate manager object:
Permission denied
2023-09-23T23:33:41.974998799+02:00 [!!] Failed to allocate manager
object.
2023-09-23T23:33:41.974998799+02:00 Exiting PID 1...: container exited
unexpectedly
The second problem is kind and minikube are both expecting Delegate=yes
to be set, which is a systemd function that allows these tools to set
cgroups limits. The limits it's expecting to control are cpu, cpuset,
memory and pids. We can force these privileges like so, echo "+cpu
+cpuset +memory +pids" >> /sys/fs/cgroup/cgroup.subtree_control
To fix the first problem we can run
g=users && sudo chgrp -R ${g} /sys/fs/cgroup/
u=$USER && sudo chown -R ${u}: /sys/fs/cgroup
These aren't harmful actions since all we're doing is changing the
cgroups file tree to be owned by our users and its users group.
Once we've addressed the first and second problem, the rest is
relatively easy: we need to make iptables (and iptables' modules so just
the package isn't enough: we need Guix's service) available. We need to
set a range of user IDs and group IDs for Podman to make use of
rootlessly, and finally we need to set a container policy otherwise Podman
can't pull any image from anywhere. All of those can be done from inside
our Guix System configuration file.
What I'd really like to see is some method for declaratively changing
the cgroups file-tree and setting limit delegation, since otherwise
these actions need to be done on every boot. I don't have the Guile
skills to pull this off but if someone fancied mentoring me, I'd be
happy to give it a shot. I have just enough ability to cobble together
a kind package from a binary (for shame, I know) and to edit the EXWM
upstream package to be based on a newer Emacs release version.
Otherwise, if there's a method of declaring these already available or
someone else can take a crack at this, please let me know!
Here's
