Re: “Build daemon drops its privileges” 👈 blog post
Ludovic Courtès writes: > But yes, providing a script for those who want to migrate would be nice. Is there any good reason for migrating, other than for testing the new setup? Konrad -- - Konrad Hinsen Centre de Biophysique Moléculaire, CNRS Orléans Synchrotron Soleil - Division Expériences Saint Aubin - BP 48 91192 Gif sur Yvette Cedex, France Tel. +33-1 69 35 97 15 E-Mail: konrad DOT hinsen AT cnrs DOT fr http://dirac.cnrs-orleans.fr/~hinsen/ ORCID: https://orcid.org/-0003-0330-9428 Mastodon: @khinsen@scholar.social -
Re: “Build daemon drops its privileges” 👈 blog post
Hi Ludo, > New blog post about this newfangled unprivileged guix-daemon: Thanks, that's useful background knowledge for the initial toot-sized announcement! And thanks to everyone who contributed to this work, which I understand wasn't exactly trivial. This opens up interesting new opportunities, some of which should help with encouraging scientific users to adopt Guix. An unexpected (for me at least) feedback to the Guix module of the Reproducible Research MOOC was: "I didn't do the exercises that required a local installation, because I feared breaking the software environment on my computer, on which I depend for my daily work." That's not an unreasonable fear, and it's an obstacle to trying out Guix. With the new daemon, it looks like we could distribute a pedagogical Guix installation as a Docker container. And that should lower the barrier to playing with it, as scientific users nowadays see the value of a Docker container as a sandbox (without necessarily seeing its limitations, but that's another story). In the long run, I'd rather have "personal Guix". Or maybe call it "guik", the little-used singular of "guix" ;-) Meaning Guix running entirely in a user's home directory. If you want a sandbox, just create a new user account for it. Unlike the Docker workaround, it would be efficient enough for real work. And it would make Guix a realistic alternative to Conda for many people. Cheers, Konrad. -- - Konrad Hinsen Centre de Biophysique Moléculaire, CNRS Orléans Synchrotron Soleil - Division Expériences Saint Aubin - BP 48 91192 Gif sur Yvette Cedex, France Tel. +33-1 69 35 97 15 E-Mail: konrad DOT hinsen AT cnrs DOT fr http://dirac.cnrs-orleans.fr/~hinsen/ ORCID: https://orcid.org/-0003-0330-9428 Mastodon: @khinsen@scholar.social -
Re: Debbugs changes on #guix
Hi there, On Thu, Mar 20 2025, Ian Eure wrote: > I think the bot messages have value I turned the messages off again, as I did not wish to make enemies. I made my point: Closing bugs takes work, and '/ignore debbugs' is not a good general policy. Kind regards, Felix P.S. Thanks to Ian and Rutherther, who still talk to me, for being such good sports!
Re: Debbugs changes on #guix
Am Mon, Mar 31, 2025 at 01:38:39PM -0700 schrieb Felix Lechner via Development of GNU Guix and the GNU System distribution.: > I turned the messages off again, as I did not wish to make enemies. Ah, that is a pity. Today I have done a lot of work on bugs and was quite happy to see that it appeared on IRC :) Andreas
Re: [GCD deliberation] Set search paths without program wrappers
Hi, I am missing any mention about the current etc/profile file inside of built Guix profiles. Is it planned to also change the function of the search paths in profiles? Because for example currently it can happen that GIO_EXTRA_MODULES will get set, because dconf is propagated into the profile, and this can break, even on Guix system, the expected so files used. The home profile packages can pick up the system so files and when the home profile hasn't been rebuilt yet, you get crashing programs. I think this means the env var needs to get effectively replaced instead, or not set at all by the profile's etc/profile file. This seems to be quite 'common' (after there start to be ABI incompatibilities, it's common for users to go asking in the irc channel about this) when libdconfsettings.so ends up in one of the search path folders. 1. After this change, are packages still going to respect the env var as well, or will the ones patched and having etc/search-path.d just ignore them completely? (replace v prepend) And if they won't ignore them, how is this incompatibility outlined higher going to be fixed, if anyhow? 1(b). What if user combines the profiles? For example, I will install python and python-numpy to system profile, then python and python-matplotlib to user profile. When I start python, which search path is actually used? Currently both are as the env var is just merged, but it doesn't seem to be possible to me with etc/search-paths.d (at least unless the various search-paths.d folders are going to be in an env var, but I think that would go against the motivation that env vars shouldn't be 'leaking'. Although they wouldn't be leaking to childs exactly, they would still be leaking from the profiles sourced.) 2. Is something going to happen to the search-paths / native-search-paths functionality of the package records in regards to guix profiles? (in other words will the generation of etc/profile file in guix profiles be afected) And if so, how exactly? I can't seem to comprehend it being removed completely as some build systems just won't have the patches, at least yet, on the other hand how would it be distinguished which ones should end up in the profile exports and which ones should just end up in the search-paths.d files? Apologies if I've just missed answers to these questions in the GCD text or discussion. Regards, Rutherther
“Build daemon drops its privileges” 👈 blog post
Hello Guix! New blog post about this newfangled unprivileged guix-daemon: https://hpc.guix.info/blog/2025/03/build-daemon-drops-its-privileges/ Feedback welcome! Ludo’.
Re: Please don't leave GNU
Hello Caleb. Caleb Herbert writes: > Please don't leave GNU Your mail alerted me; I too hope but also believe there are no such plans to leave GNU. Where have you heard? There are not yet decided discussions that GNU Guix leave Savannah and Debbugs and replace them for Codeberg/Forgejo. One argument among many (I forgot where it is from; searched on yhetil mailing list archives but cannot find it…) is that Steve George’s user survey [1] indicated users want to be told that there is a third-party channel where users can get nonfree drivers to make Guix support graphics, wifi on more kinds of hardware. Savannah does not (really?) allow telling that to users. (This seems not quite true, I think.) This is the only indication of leaving GNU that I know of. > Guix has several drawbacks that, while trivial, make it worse than > Fedora Silverblue: > > * Guix asks for my LUKS password twice Not sure of the current situation, but this was because GNU GRUB lacked support for passing on the unlocked LUKS device with a secure key derivation function or some such thing. The fix should be made upstream. > and has no Plymouth screen for > entering the LUKS password. > * Guix is slow at package management, even slower than DNF. Git-based Guix pull is slow because of Git, yes. But it must use a big Git repo for its reproducibility, transactions and it uses only one big slow repository because its package dependencies are so intertwined. > * GNU Shepherd is immature and hard to use. > * Guix uses more resources (disk space, processing power) than > conventional distros. Except for guix pull and similar commands, is that really true? The installed software is like in other package managers. > * Guix inherits legacy practices from Debian-based distros > * X11 should be Wayland > * ext4 should be btrfs or XFS > * Docker should be Podman This info is outdated when you use the latest Guix from the website or after you guix pull. GNOME on Guix System uses Wayland. There is btrfs and podman support. But GNOME Wayland is not the default in official releases yet when not upgrading. Regards, Florian [1] https://guix.gnu.org/de/blog/2025/guix-user-and-contributor-survey-2024-the-results-part-1/
Re: “Build daemon drops its privileges” 👈 blog post
Hi, On Mon, 31 Mar 2025 at 14:14, Ludovic Courtès wrote: > New blog post about this newfangled unprivileged guix-daemon: Ouf, it's on 31 march and not the 1rst April. :-D Nice feature! Thanks Ludo, thanks Reepca for the detailed review. Cheers, simon
Re: “Build daemon drops its privileges” 👈 blog post
>lun. 31 mars 2025 at 14:14, Ludovic Courtès wrote: > Feedback welcome! Loved it, great work, really useful. One comment in paragraph about "Migrating an existing installation ...", which sounds bad. It suggest that users are at their own (unless this is documented somewhere ?); "we may provide a helper script in the future ..." feels like guix-foreigners are second class citizens, which I know is usually absolutely not the case. C. signature.asc Description: PGP signature
