Hi Edouard,

Edouard Klein <[email protected]> writes:

> Hi Rutherther !
>
>
> Thank you for the explanation. I think there's an optimization to be
> made where we use only the history from the currently installed version
> on, not the full history, and then remove previous commits after an
> update. Kind of like pruning nodes do on the various blockchains.
> Implementing this securely would require months of work, so I can't
> launch myself into it right now, but I'll keep it in mind.
>
> Thanks also for your blog post ! Your implementation is extremely clean
> and integrates perfectly in a guix system. What licence is your code
> under ? Do you mind if I add this service to my channel ?

Oh, I didn't specify any license anywhere, I haven't thought of that.
Since I might try to upstream it to Guix, GNU GPL 3+.

I don't mind that at all, feel free to use it, I hope it will help you.

>
> I would like to tweak it just a little bit:
>
> #+begin_src sh
> mount -t overlay overlay -o \
> lowerdir="/root/.cache/guix",\
> upperdir="/home/$user/.cache/guix-overlay",\
> workdir="/home/$user/.cache/guix-workdir"
>  \
> "/home/$user/.cache/guix"
> bindfs --mirror=$user /home/$user/.cache/guix /home/$user/.cache/guix
> #+end_src
>
> this is what I came up with last time I had a problem with the cache
> https://the-dam.org/docs/explanations/GarbageCollection.html
>
> It solves the problem of users involuntary stepping on each others'
> toes, as well as the security issue of a user poisoning another's
> cache.
>
> The way it works is it overlays a user-writable dir over root's cache,
> and uses bindfs to make the system believe this fully owned by the user.
>
> By combining your service and this script I think we can have the best
> of both worlds :)

That seems like a possible solution for that issue, on the other hand if
I understand correctly this will basically share root -> everyone else,
rather than having everyone on the equal level where it doesn't matter
who pulls. I personally use the service I made on my computer where I
share it just with my user and root, and guix pulling as user will
ensure root doesn't have to redownload everything on guix system reconfigure.

Rutherther

>
> Thank you for your help !
>
> Edouard.
>
> Rutherther <[email protected]> writes:
>
>> Hello Edouard, 
>>
>> On June 14, 2025 11:23:33 AM GMT+02:00, Edouard Klein <[email protected]> 
>> wrote:
>>>Hi !
>>>
>>>I'm trying to let users reconfigure their home configuration on a shared
>>>guix system, but we can't all have a 700MB .cache/guix dir. I've solved
>>>part of the problem by forbidding guix pull and deploying an up-to-date
>>>system wide guix regularly.
>>>
>>>However, when running guix home reconfigure config.scm, with config.scm
>>>containing the most empty home configuration in the history of empty
>>>home configurations:
>>>
>>>#+begin_src scheme
>>>(use-modules (beaver home)
>>>             (gnu home))
>>>
>>>(-> (home-environment
>>>      (packages '())
>>>      (essential-services '())
>>>      (services '())
>>>      (location #f)))
>>>#+end_src
>>>
>>>guix dutifully pulls the whole guix repo into the cache :/
>>>
>>>I know there is a system service I can use to deploy the home
>>>configuration too, but this makes us lose the flexibility of having a
>>>user-configurable home.
>>>
>>>I think I'll maintain a systemwide cache as a workaround, but any
>>>guidance as to why guix home needs a full copy of the whole history of
>>>guix would help me understand how to get rid of that.
>>>
>>
>> Both guix home and guix system reconfigure need this to be able to check if 
>> the
>> update you are making is a forward update, and to forbid a backward one by
>> default. You can allow it by --allow-downgrades, but you will still get a
>> warning and to get that, the repo has to be pulled, fully. Then it is 
>> checked if
>> the current guix commit used for reconfigure is descendant of the previous 
>> one
>> used for reconfigure.
>>
>> There is no way to disable this currently without modifying guix source 
>> itself. 
>>
>> I came up with an idea on how to share the checkouts between multiple users
>> using bind mounts, see 
>> <https://ruther.ditigal.xyz/posts/shared-guix-checkout/>.
>> The only downside is that users could potentially corrupt the cache for 
>> other if
>> they were bad actors.
>>
>> Rutherther 
>>
>>>
>>>Thanks in advance.
>>>
>>>Edouard.

Reply via email to