all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Leo Prikler <leo.prikler@student.tugraz.at>
To: bo0od <bo0od@riseup.net>, 47846@debbugs.gnu.org
Subject: bug#47846: Feature Request: Add ability to disable having cache or generations
Date: Sat, 17 Apr 2021 22:05:00 +0200	[thread overview]
Message-ID: <34dd59bee8f503432a3eea3c55dde95a23ecc7f1.camel@student.tugraz.at> (raw)
In-Reply-To: <df61f8dd-ca00-a419-a751-46d39b1c9f00@riseup.net>

Hi,
Am Samstag, den 17.04.2021, 18:29 +0000 schrieb bo0od:
> 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.
> 
> B) System Packages: Same process but it will be saved through
> generations
There is no active caching going on.  Besides potentially building
software, the process of "upgrading" one generation of your Guix
profile or system is simply the act of letting a symbolic link point
elsewhere.  Nothing more, nothing less.  Each generation is itself a
"root" in GC terms from the moment it is built.

> This causes unpleasant actions to some users:
> 
> - Bloating the disk size
That's debatable.  Now, yes, it is no secret, that Guix uses more disk
space than your traditional software, as keeps copies of your old data
around, but on a desktop with 500MB storage, you can keep several
months of that around if you want to.  Things might be a bit different
on smartphones and embedded systems, which may want to GC more often,
but it's not like minimal setups are impossible.
> - Having old unnecessary files/packages
Which is bad how?
> - Questionable security of the saved old versions. 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)
You would have to explicitly run those old, insecure versions, for them
to be an attack surface, which I'd hazard you won't unless you're still
actively using them anyway.  Note that for the case, that the mere
existence of those is a threat, you must assume your attacker to have
arbitrary shell code execution already.

> 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).
Because it is.  There are things larger than package generations.  My
current profile weighs 8.5GB according to du, much of which can be
shared between generations.  A typical anime episode encoded with x264
at 1080p weighs 1GB or more.  So one season of your favourite show is
literally more data than all of your software.

> Current manual solution is to delete this extra mess using 2
> commands:
> 
> guix gc -d 1s && sudo guix system delete-generation
> 
> This should be run whenever there is no space left, Or to get rid of
> the 
> old stuff
Just FYI deleting all that so often only puts unnecessary stress on
your disk, because native inputs will have to be redownloaded and
you're not even freeing up that much space.

> My suggestion is to have the ability to make Guix automatically just 
> having the latest up to date packages without extra consumed storage
> (no 
> cache no generation no nothing more than having the latest packages 
> available in the distro).
That's not very functional.  Again, you're putting more stress on your
hardware by actively asking it to remove stuff.

Regards,
Leo





  parent reply	other threads:[~2021-04-17 20:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-17 18:29 bug#47846: Feature Request: Add ability to disable having cache or generations bo0od
2021-04-17 19:24 ` Leo Famulari
2021-04-17 20:05 ` Leo Prikler [this message]
2021-04-18 14:40   ` bo0od
2021-04-18 15:39     ` Leo Prikler
2021-04-18 18:45       ` bo0od
2021-04-18 19:28         ` Leo Prikler
2021-04-19 18:02           ` bo0od
2021-04-17 20:07 ` Maxime Devos
2021-04-18 10:00   ` Maxime Devos
2021-04-18 17:43   ` bo0od

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=34dd59bee8f503432a3eea3c55dde95a23ecc7f1.camel@student.tugraz.at \
    --to=leo.prikler@student.tugraz.at \
    --cc=47846@debbugs.gnu.org \
    --cc=bo0od@riseup.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.