all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: bo0od <bo0od@riseup.net>
To: Leo Prikler <leo.prikler@student.tugraz.at>, 47846@debbugs.gnu.org
Subject: bug#47846: Feature Request: Add ability to disable having cache or generations
Date: Sun, 18 Apr 2021 14:40:34 +0000	[thread overview]
Message-ID: <9520d229-1188-bf19-f8e6-9747b7a0ed11@riseup.net> (raw)
In-Reply-To: <34dd59bee8f503432a3eea3c55dde95a23ecc7f1.camel@student.tugraz.at>

 > There is no active caching going on.

Not sure what do you mean by this.

 > but on a desktop with 500MB storage, you can keep several
months of that around if you want to.

Im using 20GB+9GB swap, its nightmare you cant just upgrade without each 
and everytime delete cache. So no, Sorry The statement isnt accurate 
about 500MB. (my personal experience, not someone telling me nor 
guessing things)

 > Which is bad how?

Imagine i upgraded to FF version 79, but as well i have 78.9.2,78.9.0... 
These are wasted software we are not hunting deer and keeping trophies, 
  Dont get me wrong roll back is great/usable but not for 
everyone/everytime case.

 > You would have to explicitly run those old, insecure versions, for 
them to be an attack surface[...]

True, Already answered by Leo Famulari.

 >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.

There is no way i can upgrade without using them.

 > That's not very functional.  Again, you're putting more stress on your
hardware by actively asking it to remove stuff.

If you mean by the method of removing, Thats not my job to know what is 
the best method to be used, There are main distros like 
debian,fedora..etc devs can look at them and see how they can 
adopt/merge some methods.

Leo Prikler:
> 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
> 




  reply	other threads:[~2021-04-18 14:41 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
2021-04-18 14:40   ` bo0od [this message]
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=9520d229-1188-bf19-f8e6-9747b7a0ed11@riseup.net \
    --to=bo0od@riseup.net \
    --cc=47846@debbugs.gnu.org \
    --cc=leo.prikler@student.tugraz.at \
    /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.