Im calling the saved old versions of software cache, So if there is
better term to use good.
> * P1 is kept around in case the user isn't satisfied, or is
feeling nastolgic
> or something
Yeah this is what im suggesting to have ability to disable this behavior
as an optional choice for the user (not by default).
> In case of user packages, old generations are also saved.
Yeah no more "old" anything, Just latest fresh only.
> About 200 GiB or so in my case, though admittedly that's partially
because
> I never run "guix gc" or that command for deleting old generations
I have VM total is 29GB it goes as 20GB for guix system and 9GB swap =
nightmare of space (other distros this is more than enough specially
main/known one debian,fedora,trisquel/ubuntu...etc).
> Well, having ... They are just sitting there under /gnu/store. A user
won't
> accidentally see them or something. Aside from
> taking in disk space (see ‘Bloating the disk size’), this seems harmless.
Yeah not suitable for low space usages specially like mobile phones or
limited storage like VMs/VPS. So this is more of annoying thing to have
thus suggesting to have ability to disable it.
> As long as you don't run the old versions, you should be fine.
> If you actually run the old versions, then you'll get the old packages
> with old security bugs. If they can connect to the network, best
disconnect first.
Hmm not really always effective as guix system is as well targeting
servers so as (might be in the future) can be targeting mobile phones
both of them hard to keep internet off. But i got my answer to the
question from leo famulari which is these packages doesnt have access to
suid and thats the important part.
> Yes, but let's at least keep the last few generations around.
Yeah this is optional for each user case, The default is that guix
keeping it anyway but if someone want to disable it he should be able to
do so and use guix just for getting latest software available.
> So this would have to be run when there's only 10% disk
space left or something like that.
actually i get only 0.something left when upgrading guix on 20GB, So
without running the commands just no upgrades.
> When you've the space, I recommend keeping the ‘old stuff’ around.
> You'd never know whether you'll need it later! In case you'll need
it later[..]
Thats true but not always you are able to have more space easily,
Sometimes you are limited with payment if you are working on remote
VPS/VM or using devices which are hard/expensive changing their hard
like mobiles/tablets.
This issue doesnt talk about my own case scenario but as any other user
which might have similar circumstances and guix without this suggested
feature wont help these users.
> There's an unattended-upgrade-service for the system profile (if
that's the
> result of operating-system). Maybe we can have something similar for
user
> profiles.
Anything which can overcome the problem of having limited disk space.
> This in-place replacement you seem to be suggesting, is rather
counter one of
> the primary goals of Guix (and Nix, for that matter) --- functional
package
> management.
>
> Automatically deleting the previous profile and trying to delete the
previous
> version whenever possible could be possible, but I'm not sure it's
worth it.
Any method not a problem since this feature going to be optional side
feature anyway.
Create the suitable way of doing it and i will test and report back if
there is any problems.
> Of course, what you decide to hack on, what approaches you'll take, etc.
> is up to you!
So when i open feature request ticket i should answer myself and do it?
No, I want this from upstream to be implemented as a feature its not
about me only but any scenario which has the same problem because guix
doesnt give solutions for limited space (and 20GB is not small storage
for GNU/Linux distro)
Maxime Devos:
Toggle quote (140 lines)
> bo0od schreef op za 17-04-2021 om 18:29 [+0000]:
>> Hi There,
>>
>> Current situation with the guix distro upgrade is:(as i understand)
>>
>> A) User Packages: whenever there is an upgrade to package A version 1 to
>> new Version lets call it A version 2 , So the process is ADD A2 → SWITCH
>> to A2 → Cache A1 and so on.
>
> There isn't really any caching, it's more like garbage collection like in
> Guile, other Schemes & lisps, Java, ..., where old objects (package versions
> & profiles that aren't referred anywhere anymore) are deleted.
>
> Is that informative for you?
>
> When the user upgrades A from version A1 to version A2, creating a new version
> of the profile P2:
>
> * P1: original profile, referring to the binaries of A1
> (and other packages, which I'll ignore here)
> * The user asks guix to upgrade from A1 to A2. So guix first builds A2.
> * Guix creates a profile P2, referring to the binaries of A2
> * P2 becomes the current profile.
> * P1 is kept around in case the user isn't satisfied, or is feeling nastolgic
> or something
>
>> B) System Packages: Same process but it will be saved through generations
>
> In case of user packages, old generations are also saved.
> Try "guix package --list-generations". I have 128 generations of bloat.
> Lemme update ("guix package -u"), soon I'll have 129 generations of bloat.
>
> So the bloat is even worse, and your point is even more compelling!
>
>> This causes unpleasant actions to some users:
>>
>> - Bloating the disk size
>
> About 200 GiB or so in my case, though admittedly that's partially because
> I never run "guix gc" or that command for deleting old generations
>
>> - Having old unnecessary files/packages
>
> Well, having ... They are just sitting there under /gnu/store. A user won't
> accidentally see them or something. Aside from
> taking in disk space (see ‘Bloating the disk size’), this seems harmless.
>
>> - Questionable security of the saved old versions.
>
> As long as you don't run the old versions, you should be fine.
> If you actually run the old versions, then you'll get the old packages
> with old security bugs. If they can connect to the network, best disconnect
> first.
>
> Only run old (and therefore possibly with publicly-known and unfixed security
> issues) issues on trusted data! Use case I have in mind:
>
> /.../old-profile-version/bin/tome4 (when you've disabled Internet access,
> for trying an old version of tome4 (a game) to see what has changes since).
>
>> As it depend if they
>> have access to suid or not (i didnt investigate this, but if they have
>> then thats big problem but this is not the ticket to discuss it)
>
> "guix package -i" never creates setuid/setgid binaries. The only setuid/setgid
> binaries that guix creates are in /run/setuid-programs. These are setuid/setgid
> _copies_ of what's requested in the _current_ (or the one at boot, I forgot)
> operating-system declaration.
>
>> I know someone would jump in and say but roll back is great feature and
>> its useful and....i know that but like i said might be not suiting all
>> users (specially with limited space).
>
> Yes, but let's at least keep the last few generations around.
>
> E.g., I actually _almost_ never use the rollback mechanism. The only
> time was when I messed up the operating-system declaration, so I had to boot
> into the previous system generation (is that the term?).
>
> Of course, then there's a choice to make for _how many_ generations to keep
> around ...
>
>> Current manual solution is to delete this extra mess using 2 commands:
>>
>> guix gc -d 1s && sudo guix system delete-generation
>
> You should run them in the opposite order.
> Also, "guix package --delete-generations" should be run for each user.
>
>> This should be run whenever there is no space left,
>
> Tricky ... reportedly, many software does not handle out-of-disk-space errors
> well. Also, letting "guix gc" and "guix package --delete-generations" run
> takes some time. So this would have to be run when there's only 10% disk
> space left or something like that.
>
>> Or to get rid of the old stuff
>
> When you've the space, I recommend keeping the ‘old stuff’ around.
> You'd never know whether you'll need it later! In case you'll need it later,
> keeping the ‘old stuff’ around saves on Internet traffic (saving some time)
> (lessening the load on the substitute servers -> less network and disk I/O and
> CPU usage --> less monetary costs, less environmental cost).
>
>> My suggestion is to have the ability to make Guix automatically just
>> having the latest up to date packages
>
> There's an unattended-upgrade-service for the system profile (if that's the
> result of operating-system). Maybe we can have something similar for user
> profiles.
>
>> without extra consumed storage (no cache no generation no nothing more than
>> having the latest packages available in the distro).
>>
>> So the process is ADD A2 → SWITCH to A2 → Delete A1 , Or Download A2 →
>> Replace over A1 and so on.
>
> This in-place replacement you seem to be suggesting, is rather counter one of
> the primary goals of Guix (and Nix, for that matter) --- functional package
> management.
>
> Automatically deleting the previous profile and trying to delete the previous
> version whenever possible could be possible, but I'm not sure it's worth it.
>
> You could try to implement it yourself, and try your modified guix out for
> a while, and report whether it seems to work well, of course!
>
> However, I believe the following would be easier in the short term
> (and *very* likely to be accepted upstream):
>
> Implement a graphical application (maybe using the guile-gnome bindings,
> or as a web app run on localhost) that has a few buttons for collecting
> garbage and deleting old profiles. Guix could use some graphical stuff.
>
> Of course, what you decide to hack on, what approaches you'll take, etc.
> is up to you!
>
> Greetings,
> Maxime
>
