From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:bcc0::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id lkvbG7d+fGCBVQEAgWs5BA (envelope-from ) for ; Sun, 18 Apr 2021 20:47:19 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id mF58FLd+fGB8LgAAbx9fmQ (envelope-from ) for ; Sun, 18 Apr 2021 18:47:19 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 9752A1AB88 for ; Sun, 18 Apr 2021 20:47:18 +0200 (CEST) Received: from localhost ([::1]:45620 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lYCRw-0007lR-Rr for larch@yhetil.org; Sun, 18 Apr 2021 14:47:16 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60978) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lYCQo-0007Jj-M5 for bug-guix@gnu.org; Sun, 18 Apr 2021 14:46:08 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:36233) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lYCQl-0003xU-19 for bug-guix@gnu.org; Sun, 18 Apr 2021 14:46:06 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lYCQk-0006c6-Vk for bug-guix@gnu.org; Sun, 18 Apr 2021 14:46:02 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#47846: Feature Request: Add ability to disable having cache or generations Resent-From: bo0od Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sun, 18 Apr 2021 18:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47846 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Leo Prikler , 47846@debbugs.gnu.org Received: via spool by 47846-submit@debbugs.gnu.org id=B47846.161877152925351 (code B ref 47846); Sun, 18 Apr 2021 18:46:02 +0000 Received: (at 47846) by debbugs.gnu.org; 18 Apr 2021 18:45:29 +0000 Received: from localhost ([127.0.0.1]:47775 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYCQD-0006ap-59 for submit@debbugs.gnu.org; Sun, 18 Apr 2021 14:45:29 -0400 Received: from mx1.riseup.net ([198.252.153.129]:47248) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYCQB-0006ab-Tr for 47846@debbugs.gnu.org; Sun, 18 Apr 2021 14:45:28 -0400 Received: from fews1.riseup.net (fews1-pn.riseup.net [10.0.1.83]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4FNf5M6SSQzDv4S; Sun, 18 Apr 2021 11:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1618771522; bh=KhyVytunn2q3TVLI4j2ctx4BLAssn0QeB/lJ6a2W018=; h=Subject:To:References:From:Date:In-Reply-To:From; b=itkfPSGoLalgbO0jxKRvTAwFiJY1YKXmgRXR/DyjgwXc3KMNt5rJCTVZSvXTHRc7z EQHrtdCZJNMGQXT1hrmwO87zf9dA/tzPvHsYAn2Cq2cej3b+13K+7mFQ7wKe8p9zaL dsc1KuAV7JRM3nvHOHukrbjs/WirM+0io8LjhsM0= X-Riseup-User-ID: 1CF75E676A191BAEE0FB21C1FAB15A04C4F5307EEED84C5AB19BFDF367851548 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews1.riseup.net (Postfix) with ESMTPSA id 4FNf5L1Y1Jz5w5X; Sun, 18 Apr 2021 11:45:09 -0700 (PDT) References: <34dd59bee8f503432a3eea3c55dde95a23ecc7f1.camel@student.tugraz.at> <9520d229-1188-bf19-f8e6-9747b7a0ed11@riseup.net> <673a04816e4ea2e12d4dfda2cda43ec64eb0d50d.camel@student.tugraz.at> From: bo0od Message-ID: <6d08fb6e-8fb6-8990-aa85-423bcc4f9ddd@riseup.net> Date: Sun, 18 Apr 2021 18:45:05 +0000 MIME-Version: 1.0 In-Reply-To: <673a04816e4ea2e12d4dfda2cda43ec64eb0d50d.camel@student.tugraz.at> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1618771638; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=b1mzCMCPsOFs6iviWkRmwVn4jOBEkWsr2pWyNCzLlD8=; b=qhzy+FIUOfG3oFIh2L6yO+LtvA8+SufqpqO8AOWneg2jlTXJlWSPZ4CKu3Qpqba47PETXN 3tf2XJZJQZouCw0+yUOKtmMywQC4Qu2ktOPzYN65GEd0nJQaU7lm6fTo/I7nE8Gb2jtE4e wgwVTzfUhrStapp/mmezwtPdK7MnH+kC1+NRtM3ajudD4i9XJjLsVVry9anLolRH0X/LkF IoN3FSaPHRPARkZPqqGV3NBA3SEyx7ufGbiAlEo27YS4hHHpbfF8YjZOPFCk8F9dWU2yNz tMG2gJRW43Dcsuaxmd2mTMczYR+6n7uYE3Wouhsmn0w90SHGdEWxS+qE0Vr2FA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1618771638; a=rsa-sha256; cv=none; b=tYM4sKN0Pd4kXhjRW/0sVC5r98Cz0kyfZdjLpyykPrkfyzaDhVvQXk7DdI1c2CQrIyyuvn vtjC9tp8j++mmy6C1BXUxX0OL8QCn5AEAkcpadpyQMWHxXrh7wE2LQ7+ocQfXzF98XSMYU tLcqmN18CSvgylki97QHDVc5mofdVY4JRy7+H4mnW6/Wlf65LpjADPLAUlJD4e2RMTFNGE NFUL3IVjdDoiI5wxUCGfua0lQeShyko8sy+pp0BwOKGECQHt/dgX2PpDOCB2iG4iy2TK0J RleI+M/1Dw9dgdMI0LFq9XKKV208NLVzQ6xpC/cd5amc20Kix/FF+mlqOMwuoA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=riseup.net header.s=squak header.b=itkfPSGo; dmarc=fail reason="SPF not aligned (relaxed)" header.from=riseup.net (policy=none); spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Migadu-Spam-Score: -1.34 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=riseup.net header.s=squak header.b=itkfPSGo; dmarc=fail reason="SPF not aligned (relaxed)" header.from=riseup.net (policy=none); spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Migadu-Queue-Id: 9752A1AB88 X-Spam-Score: -1.34 X-Migadu-Scanner: scn0.migadu.com X-TUID: UMPlraAPjYfS > My bad, I meant to type 500GB (a fairly common disk size), but it turns > out my other laptop survives quite fine on 250. Fair enough, it's not > 32GB (common in phones), but then again, you'd run normally very > different packages on embedded systems. yeah 100+ GB thats too big, not always having this space is easy or available. > There are several ways of optimizing for profile size, one of which is > to not run huge browsers like icecat. I have no idea what kind of > system you're trying to fit into 20GB , but a hard idea thinking it's > the right kind. I have debian,fedora,kali,ubuntu,trisquel/triskel,arch... all with only 20GB space and working for testing purposes as im mostly working as software tester. > What kind of advanced removal strategies are you talking about? I didnt suggested how its done in my ticket, I gave the issue and feature request as a solution to it but how to do it the best way i leave this to the devs to decide not me. If out of ideas and nothing is available look at other distributions and see how its done and what can be taken from them and merge into guix to adopt this feature. Leo Prikler: > Hi, > > Am Sonntag, den 18.04.2021, 14:40 +0000 schrieb bo0od: >> > There is no active caching going on. >> >> Not sure what do you mean by this. > Exactly what I said. There is a philosophical difference between a > store, that keeps items as long as there's a referrer and a cache, > which keeps some items on a heuristic basis. > >> > 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) > My bad, I meant to type 500GB (a fairly common disk size), but it turns > out my other laptop survives quite fine on 250. Fair enough, it's not > 32GB (common in phones), but then again, you'd run normally very > different packages on embedded systems. > > And yeah, this is also personal experience, not someone telling me or > guessing, I merely made a typo. > >> >> > 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 do know, that Guix also has environments, that can be garbage > collected, as soon as the process exits, right? If you use Icecat so > rarely, that upgrading it along with the rest of your profile makes no > sense, you could use those. Not to mention w.r.t. security, using a > containerized icecat is probably a better idea. > >> >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. > There are several ways of optimizing for profile size, one of which is > to not run huge browsers like icecat. I have no idea what kind of > system you're trying to fit into 20GB , but a hard idea thinking it's > the right kind. > > By the way, continuing from before, my /run/current-system, which > consists of the desktop template plus some extras, seems to weigh just > about 2GB, which would fit 5 times into 20GB while still letting me use > half of the disk. > >> > 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. > What kind of advanced removal strategies are you talking about? > Traditional distros do not face this issue, because they're more or > less just dumping files into already existing locations, and don't > really worry whether something already exists there. (Well, there are > varying degrees of worrying, but they are all incomplete.) Binary > distros have it even easier, because they don't even attempt to build > from source (another issue if you're running a resource-constrained > device). > > These so-called "removal methods" of traditional distros are > antithetical to Guix' design. Asking us to behave just like a "main > distro", when we have made a clear decision not to, is not going to > please either side of the discussion. > > Regards, > Leo >