[Patch staging ] doc add a recommended system in 'Hardware Considerations'

  • Done
  • quality assurance status badge
Details
5 participants
  • Joshua Branson
  • kiasoc5
  • Ludovic Courtès
  • Christopher Baines
  • pelzflorian (Florian Pelz)
Owner
unassigned
Submitted by
Joshua Branson
Severity
normal
J
J
Joshua Branson wrote on 7 Oct 2022 16:24
(address . guix-patches@gnu.org)
20221007142445.25162-1-jbranso@dismail.de
It would be nice if the guix manual mentioned that it really works best with
2GB of RAM. and that the best supported archeteticure is X86_64.

* doc/guix.texi (Hardware Considerations): add a reccomended system and a
short commentary about graphics cards.
---
doc/guix.texi | 11 +++++++++++
1 file changed, 11 insertions(+)

Toggle diff (31 lines)
diff --git a/doc/guix.texi b/doc/guix.texi
index f8badfb5a9..1d1cec6e0d 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -2218,6 +2218,13 @@ Linux-libre driver. Free firmware exists for both and is available
out-of-the-box on Guix System, as part of @code{%base-firmware}
(@pxref{operating-system Reference, @code{firmware}}).
+@cindex Graphics Cards, hardware support
+Graphics cards have a hard time running properly under linux-libre,
+because those drivers usually require propritary firmware, which
+linux-libre removes. Users should avoid brand new graphics cards.
+Older Kepler Nvidia graphics cards and integrated Intel GPUs work the
+best.
+
@cindex RYF, Respects Your Freedom
The @uref{https://www.fsf.org/, Free Software Foundation} runs
@uref{https://www.fsf.org/ryf, @dfn{Respects Your Freedom}} (RYF), a
@@ -2229,6 +2236,10 @@ Another useful resource is the @uref{https://www.h-node.org/, H-Node}
web site. It contains a catalog of hardware devices with information
about their support in GNU/Linux.
+For the best Guix System experience, Guix developers recommend an X86_64
+system with at least 2GB of RAM. An old Thinkpad in the T or X series
+is usually a good choice. If you decide to run Guix System on ARM or
+Power architectures, then please use a system with a 64 bit CPU.
@node USB Stick and DVD Installation
@section USB Stick and DVD Installation
--
2.37.3
P
P
pelzflorian (Florian Pelz) wrote on 8 Oct 2022 11:55
(name . Joshua Branson via Guix-patches via)(address . guix-patches@gnu.org)
87czb2ljvt.fsf@pelzflorian.de
Hmm Joshua, recommending these thinkpads may be good or may be bad.

Off-the-shelf hardware too often is at odds with freedom, and newcomers
underestimate how hard it is to find hardware.

Joshua Branson via Guix-patches via <guix-patches@gnu.org> writes:
Toggle quote (3 lines)
> * doc/guix.texi (Hardware Considerations): add a reccomended system and a
> short commentary about graphics cards.

For graphics cards https://issues.guix.gnu.org/36786 “Warn of AMD GPUs
unusable with Guix System” is related. As Ricardo said there, we do
point to h-node.

Toggle quote (7 lines)
> +@cindex Graphics Cards, hardware support
> +Graphics cards have a hard time running properly under linux-libre,
> +because those drivers usually require propritary firmware, which
> +linux-libre removes. Users should avoid brand new graphics cards.
> +Older Kepler Nvidia graphics cards and integrated Intel GPUs work the
> +best.

It would be bad to make recommendations that end up not working. I have
doubts if new Intel GPUs is a safe advise.

Toggle quote (5 lines)
> +For the best Guix System experience, Guix developers recommend an X86_64
> +system with at least 2GB of RAM. An old Thinkpad in the T or X series
> +is usually a good choice. If you decide to run Guix System on ARM or
> +Power architectures, then please use a system with a 64 bit CPU.

IMHO ARM and Power need not be mentioned so explicitly. On the website,
there is no Guix System download link for ARM except the Pinebook image
(I don’t own a Pinebook and can’t test that). Guix on ARM works well,
now that rsvg works on ARM.

And once there is a new release, bordeaux will be enabled by default,
then Guix on ARM will be much better even by default.

Regards,
Florian
J
J
jbranso wrote on 8 Oct 2022 17:33
3132924a6c819b24e814f67b1e3b75da@dismail.de
October 8, 2022 5:56 AM, "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> wrote:

Toggle quote (2 lines)
> Hmm Joshua, recommending these thinkpads may be good or may be bad.

Thanks for the response Florian! I'm a bit curious. Do you think that
I should try to re-word what I've said? I can resend another patch, if
you think it appropriate.
Toggle quote (3 lines)
> Off-the-shelf hardware too often is at odds with freedom, and newcomers
> underestimate how hard it is to find hardware.

Can you give me some examples of "bad thinkpads"? Perhaps really new
ones? I'm honestly a little torn about what hardware to recommend to
newcomers to Guix System. I cannot maintain my integrity and recommend
a librebooted laptop. I use an osbooted Thinkpad, because with the
cpu microkernel updates, the laptop is SOOO much more stable.
My librebooted laptop would crash whenever I tried doing video editing.

Perhaps we should list sellers that sell hardware with Guix system
pre-installed. I see in reddit, people asking with some frequency
what hardware they should buy for Guix System. It would be nice to
at least recommend some specific hardware. :) I think the current
manual is too vague for newcomers. Just my 2 cents.

Or maybe this wiki page may be of use:


Toggle quote (9 lines)
> Joshua Branson via Guix-patches via <guix-patches@gnu.org> writes:
>
>> * doc/guix.texi (Hardware Considerations): add a reccomended system and a
>> short commentary about graphics cards.
>
> For graphics cards <https://issues.guix.gnu.org/36786> “Warn of AMD GPUs
> unusable with Guix System” is related. As Ricardo said there, we do
> point to h-node.

Thanks for pointing me to that!

Toggle quote (11 lines)
>
>> +@cindex Graphics Cards, hardware support
>> +Graphics cards have a hard time running properly under linux-libre,
>> +because those drivers usually require propritary firmware, which
>> +linux-libre removes. Users should avoid brand new graphics cards.
>> +Older Kepler Nvidia graphics cards and integrated Intel GPUs work the
>> +best.
>
> It would be bad to make recommendations that end up not working. I have
> doubts if new Intel GPUs is a safe advise.

I can re-word to to say "old integrated Intel GPUs". I'm not sure how
old I should say though. 5 years? Will the Intel Arc graphics cards
be FYF or do they have a binary blob. I don't actually know...

Toggle quote (11 lines)
>
>> +For the best Guix System experience, Guix developers recommend an X86_64
>> +system with at least 2GB of RAM. An old Thinkpad in the T or X series
>> +is usually a good choice. If you decide to run Guix System on ARM or
>> +Power architectures, then please use a system with a 64 bit CPU.
>
> IMHO ARM and Power need not be mentioned so explicitly. On the website,
> there is no Guix System download link for ARM except the Pinebook image
> (I don’t own a Pinebook and can’t test that). Guix on ARM works well,
> now that rsvg works on ARM.

How recent was that? That rsvg started working on ARM ?

Toggle quote (4 lines)
>
> And once there is a new release, bordeaux will be enabled by default,
> then Guix on ARM will be much better even by default.

I certainly hope so!

Toggle quote (2 lines)
> Regards,
> Florian
P
P
pelzflorian (Florian Pelz) wrote on 10 Oct 2022 12:07
(address . jbranso@dismail.de)
87pmf0htzb.fsf@pelzflorian.de
jbranso@dismail.de writes:
Toggle quote (4 lines)
> Can you give me some examples of "bad thinkpads"? Perhaps really new
> ones? I'm honestly a little torn about what hardware to recommend to
> newcomers to Guix System.

Your patch addresses many things at once; mostly I wanted to refer you
to the AMD GPU bug. My experience was being quite disgruntled when I
learned AMD had only “free” drivers marketing-wise but not truly free
drivers because no free firmware.

My opposition to recommending Thinkpads is mostly opposition to
recommending specific hardware, which should be the job of RYF and
h-node. Guix cannot keep track.

Toggle quote (4 lines)
> Or maybe this wiki page may be of use:
>
> https://wiki.parabola.nu/Computers

Your Parabola link is really interesting though; it makes it sound like
even RYF hardware is not without wi-fi trouble …

When you write

Toggle quote (4 lines)
> It would be nice to
> at least recommend some specific hardware. :) I think the current
> manual is too vague for newcomers. Just my 2 cents.

then I do agree, but I also think it cannot be in scope for Guix.


Toggle quote (4 lines)
> I can re-word to to say "old integrated Intel GPUs". I'm not sure how
> old I should say though. 5 years? Will the Intel Arc graphics cards
> be FYF or do they have a binary blob. I don't actually know...

H-node says some Intel UHD have no 3d acceleration.


Toggle quote (3 lines)
> How recent was that? That rsvg started working on ARM ?


commit 32a87714f4507f853824d82d9c6ca10e1405c8eb
Author: Pierre Langlois <pierre.langlois@gmx.com>
Date: Sat Mar 26 13:21:17 2022 +0000

gnu: mrustc: Update to 0.10.
And enable rust for aarch64-linux!


A very nice commit message. :)

Regards,
Florian
L
L
Ludovic Courtès wrote on 14 Oct 2022 17:12
Re: bug#58357: [Patch staging ] doc add a recommended system in 'Hardware Considerations'
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
87edval9qc.fsf_-_@gnu.org
Hi!

This discussion and others we had at the Ten Years of Guix event makes
me think we should strive to avoid bad surprises by being more
explicit. Concretely, we could:

• Under “Hardware Considerations”, list common devices known not to
work without non-free {firm,soft}ware, such as Intel Wifi (iwlwifi).
We cannot be exhaustive but we should at least mention common
problems with recent x86_64 laptops.

• Under “Hardware Considerations”, make the list of devices known to
work clearer, in tabular form, perhaps expanding it.

• In the installer, print a message upfront when unusable devices are
found—typically Intel wifi.

I’m not sure how to do this though. Maintaining a list of known-bad
devices doesn’t sound great, but it’s better than nothing.
Instrumenting the firmware-loading mechanism would be a good way to
detect problems, but I think it’s not even getting invoked in
Linux-libre (or not always). Alternatively, we could tweak
deblobbing so that it produces a list of known-bad modules or
devices.

Thoughts?

Ludo’.
K
K
kiasoc5 wrote on 14 Oct 2022 17:47
Re: [bug#58357] [Patch staging ] doc add a recommended system in 'Hardware Considerations'
(name . Ludovic Courtès)(address . ludo@gnu.org)
20221014154734.6ac73a89@aria
On Fri, Oct 14 2022, 05:12:59 PM +0200
Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (8 lines)
> I’m not sure how to do this though. Maintaining a list of
> known-bad devices doesn’t sound great, but it’s better than nothing.
> Instrumenting the firmware-loading mechanism would be a good way
> to detect problems, but I think it’s not even getting invoked in
> Linux-libre (or not always). Alternatively, we could tweak
> deblobbing so that it produces a list of known-bad modules or
> devices.

I think automatically generating a list of nonfree modules would work,
as long as we make sure we don't recommend that a user acquire them.

Also, I tried to run linux-libre on my desktop and it booted but
refused to login because it tried to load the nonfree wifi card. Could
it be patched so that nonfree modules are ignored, and I could at least
get a desktop without wifi? Everything else afaik is free hardware.

(if this is a separate issue, I can make a bug report)

--
P
P
pelzflorian (Florian Pelz) wrote on 14 Oct 2022 19:09
Re: bug#58357: [Patch staging ] doc add a recommended system in 'Hardware Considerations'
(name . Ludovic Courtès)(address . ludo@gnu.org)
87sfjqqqm7.fsf@pelzflorian.de
Hello! Some comments:

Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (9 lines)
> This discussion and others we had at the Ten Years of Guix event makes
> me think we should strive to avoid bad surprises by being more
> explicit. Concretely, we could:
>
> • Under “Hardware Considerations”, list common devices known not to
> work without non-free {firm,soft}ware, such as Intel Wifi (iwlwifi).
> We cannot be exhaustive but we should at least mention common
> problems with recent x86_64 laptops.

My impression is that the dire wifi situation is explained well enough
in Hardware Considerations already.

On other common problems, even if I no longer agree with all I wrote at
https://issues.guix.gnu.org/36786, I remember that others claimed
somewhere that not all AMD GPUs are bad, and h-node says some Intel
integrated graphics are indeed not working, so it is not easy to
generalize when it comes to GPUs.


Toggle quote (3 lines)
> • Under “Hardware Considerations”, make the list of devices known to
> work clearer, in tabular form, perhaps expanding it.

There is a list of image types like novena and pine64. The Pinebook
image is even on the website, which is kind of more prominent than the
manual. Then there also are bootloaders for some devices in the Guix
source code (not prominent at all).

By the way, it did play a part when my family bought an odroid c2 that
Guix had a bootloader for it, then there came a commit

commit 2bb915e679b8a9e071f15b4caa3274fe9c6396c1
Author: Efraim Flashner <efraim@flashner.co.il>
Date: Thu Apr 19 17:24:40 2018 +0300

gnu: u-boot-odroid-c2: Remove variable.
U-boot for this target requires a binary blob to boot correctly.
* gnu/packages/bootloaders.scm (u-boot-odroid-c2): Remove variable.

(There never was a recommendation for odroid though and we don’t regret
buying it. But recommendations could be dangerous.)


Toggle quote (4 lines)
>
> • In the installer, print a message upfront when unusable devices are
> found—typically Intel wifi.

Yes, I agree there should somehow be a warning for example if the
uvesafb module gets loaded. I need to think about that.

Regards,
Florian
J
J
jbranso wrote on 14 Oct 2022 21:28
fd4f624a3d5ee6942a42e45d3dcbef21@dismail.de
October 14, 2022 1:10 PM, "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> wrote:

Toggle quote (14 lines)
> Hello! Some comments:
>
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> This discussion and others we had at the Ten Years of Guix event makes
>> me think we should strive to avoid bad surprises by being more
>> explicit. Concretely, we could:
>>
>> • Under “Hardware Considerations”, list common devices known not to
>> work without non-free {firm,soft}ware, such as Intel Wifi (iwlwifi).
>> We cannot be exhaustive but we should at least mention common
>> problems with recent x86_64 laptops.
>

OpenBSD lists supported hardware on their website:


Joshua
P
P
pelzflorian (Florian Pelz) wrote on 15 Oct 2022 11:47
Re: [bug#58357] [Patch staging ] doc add a recommended system in 'Hardware Considerations'
(name . kiasoc5)(address . kiasoc5@disroot.org)
87v8oll8oz.fsf@pelzflorian.de
kiasoc5 <kiasoc5@disroot.org> writes:
Toggle quote (5 lines)
> Also, I tried to run linux-libre on my desktop and it booted but
> refused to login because it tried to load the nonfree wifi card. Could
> it be patched so that nonfree modules are ignored, and I could at least
> get a desktop without wifi? Everything else afaik is free hardware.

Are you sure this is not a graphics lockup? If it were a graphics
lockup, you could press E in the GRUB menu and add nomodeset to the
linux boot line.

Regards,
Florian
P
P
pelzflorian (Florian Pelz) wrote on 15 Oct 2022 17:51
(name . Ludovic Courtès)(address . ludo@gnu.org)
87sfjpw0e3.fsf@pelzflorian.de
"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes:
Toggle quote (3 lines)
> Yes, I agree there should somehow be a warning for example if the
> uvesafb module gets loaded. I need to think about that.

I sent a separate patch for uvesafb as https://issues.guix.gnu.org/58549

Regards,
Florian
P
P
pelzflorian (Florian Pelz) wrote on 16 Oct 2022 13:53
(name . kiasoc5)(address . kiasoc5@disroot.org)
87ilkkouge.fsf@pelzflorian.de
"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes:
Toggle quote (10 lines)
> kiasoc5 <kiasoc5@disroot.org> writes:
>> Also, I tried to run linux-libre on my desktop and it booted but
>> refused to login because it tried to load the nonfree wifi card. Could
>> it be patched so that nonfree modules are ignored, and I could at least
>> get a desktop without wifi? Everything else afaik is free hardware.
>
> Are you sure this is not a graphics lockup? If it were a graphics
> lockup, you could press E in the GRUB menu and add nomodeset to the
> linux boot line.

gnu/system.scm contains

(define %default-modprobe-blacklist
;; List of kernel modules to blacklist by default.
'("usbmouse" ;races with bcm5974, see https://bugs.gnu.org/35574
"usbkbd")) ;races with usbhid, see https://issues.guix.gnu.org/35574#18

Perhaps send a patch or open a bug to add your wifi’s module to the
default modprobe blacklist.

Regards,
Florian
L
L
Ludovic Courtès wrote on 17 Oct 2022 18:35
Re: bug#58357: [Patch staging ] doc add a recommended system in 'Hardware Considerations'
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
87zgdupfwr.fsf@gnu.org
Hi,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

Toggle quote (13 lines)
> Ludovic Courtès <ludo@gnu.org> writes:
>> This discussion and others we had at the Ten Years of Guix event makes
>> me think we should strive to avoid bad surprises by being more
>> explicit. Concretely, we could:
>>
>> • Under “Hardware Considerations”, list common devices known not to
>> work without non-free {firm,soft}ware, such as Intel Wifi (iwlwifi).
>> We cannot be exhaustive but we should at least mention common
>> problems with recent x86_64 laptops.
>
> My impression is that the dire wifi situation is explained well enough
> in Hardware Considerations already.

It is, but:

1. It’s not as prominent and explicit as it could be: it’s within a
paragraph (as opposed to a table), there’s no mention of iwlwifi,
etc.

2. The situation got worse in the meantime: see “Background” in

Toggle quote (5 lines)
>> • Under “Hardware Considerations”, make the list of devices known to
>> work clearer, in tabular form, perhaps expanding it.
>
> There is a list of image types like novena and pine64.

By devices, I meant primarily WiFi devices, sound cards, etc. for the
more common x86_64 hardware.

Thanks,
Ludo’.
C
C
Christopher Baines wrote on 3 Nov 2022 16:50
tag 58357 moreinfo
(address . control@debbugs.gnu.org)
87h6zg82b2.fsf@cbaines.net
tags 58357 + moreinfo
quit
L
L
Ludovic Courtès wrote on 3 Nov 2022 20:21
Re: bug#58357: [Patch staging ] doc add a recommended system in 'Hardware Considerations'
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
87h6zfoncw.fsf_-_@gnu.org
Hi,

Ludovic Courtès <ludo@gnu.org> skribis:

Toggle quote (19 lines)
> • Under “Hardware Considerations”, list common devices known not to
> work without non-free {firm,soft}ware, such as Intel Wifi (iwlwifi).
> We cannot be exhaustive but we should at least mention common
> problems with recent x86_64 laptops.
>
> • Under “Hardware Considerations”, make the list of devices known to
> work clearer, in tabular form, perhaps expanding it.
>
> • In the installer, print a message upfront when unusable devices are
> found—typically Intel wifi.
>
> I’m not sure how to do this though. Maintaining a list of known-bad
> devices doesn’t sound great, but it’s better than nothing.
> Instrumenting the firmware-loading mechanism would be a good way to
> detect problems, but I think it’s not even getting invoked in
> Linux-libre (or not always). Alternatively, we could tweak
> deblobbing so that it produces a list of known-bad modules or
> devices.

Here’s a contribution for this last item:


Feedback welcome!

Ludo’.
P
P
pelzflorian (Florian Pelz) wrote on 16 Nov 2022 01:22
Re: [bug#58357] [Patch staging ] doc add a recommended system in 'Hardware Considerations'
(name . Joshua Branson)(address . jbranso@dismail.de)(address . 58357@debbugs.gnu.org)
871qq3bvdy.fsf@pelzflorian.de
Hello Joshua,

* Ludo added warnings about unsupported hardware to the installer:

* I’m still not fond of recommending specific hardware. That’s what RYF
is for, and RYF gets mentioned in the docs.

* But: Maybe the 2GB requirement should be documented after all.

IIRC someone somewhere suggested treating such high RAM usage a bug
and reducing module imports, for example, but not add a memory
requirement to the documentation. I run a guix search and think the
de-facto requirement is somewhere slightly above 1GB? But I guess I
test wrongly.

I’m keeping this bug open because of the RAM thing. WDYT?

Regards,
Florian
J
J
jbranso wrote on 17 Nov 2022 00:16
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)(address . 58357@debbugs.gnu.org)
9c02cf345e530d8766d842028ee0501f@dismail.de
November 15, 2022 7:23 PM, "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> wrote:

Toggle quote (18 lines)
> Hello Joshua,
>
> * Ludo added warnings about unsupported hardware to the installer:
> <https://issues.guix.gnu.org/59003>.
>
> * I’m still not fond of recommending specific hardware. That’s what RYF
> is for, and RYF gets mentioned in the docs.
>
> * But: Maybe the 2GB requirement should be documented after all.
>
> IIRC someone somewhere suggested treating such high RAM usage a bug
> and reducing module imports, for example, but not add a memory
> requirement to the documentation. I run a guix search and think the
> de-facto requirement is somewhere slightly above 1GB? But I guess I
> test wrongly.
>
> I’m keeping this bug open because of the RAM thing. WDYT?

I can submit a patch in the guix manual to recommend hardware with at least
1 or 2GB. Which is better? 1 or 2?

Toggle quote (3 lines)
>
> Regards,
> Florian
P
P
pelzflorian (Florian Pelz) wrote on 17 Nov 2022 17:26
(address . jbranso@dismail.de)(address . 58357@debbugs.gnu.org)
87wn7tk0nv.fsf@pelzflorian.de
jbranso@dismail.de writes:
Toggle quote (3 lines)
> I can submit a patch in the guix manual to recommend hardware with at least
> 1 or 2GB. Which is better? 1 or 2?

Come to think of it, there recently was a commit about Guix System (not
about but because of the Guix package manager):

commit 98a8b48a69b8208475c9a1e40d09517f8643b8cb
Author: Ludovic Courtès <ludo@gnu.org>
Date: Thu Sep 1 14:45:45 2022 +0200

doc: Suggest more RAM for "Running Guix in a VM".
Reported by Michael F. Lamb <mike@orbital.rodeo>.
Running 'guix pull' to target current revisions would lead to memory
exhaustion. Bumping the memory size works around that.
* doc/guix.texi (Running Guix in a VM): Change "-m 1024" to "-m 2048".


However, to quote Ludo from that bug#57474:
Toggle quote (3 lines)
> It looks like the memory requirements to build the latest revisions of
> Guix have increased (and this is a bit ridiculous).

Nevertheless the docs should mention 2GB, I guess.

Regards,
Florian
J
J
Joshua Branson wrote on 19 Nov 2022 15:06
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)(address . 58357@debbugs.gnu.org)
87iljbujgo.fsf@dismail.de
"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes:

Toggle quote (29 lines)
> jbranso@dismail.de writes:
>> I can submit a patch in the guix manual to recommend hardware with at least
>> 1 or 2GB. Which is better? 1 or 2?
>
> Come to think of it, there recently was a commit about Guix System (not
> about but because of the Guix package manager):
>
> commit 98a8b48a69b8208475c9a1e40d09517f8643b8cb
> Author: Ludovic Courtès <ludo@gnu.org>
> Date: Thu Sep 1 14:45:45 2022 +0200
>
> doc: Suggest more RAM for "Running Guix in a VM".
>
> Fixes <https://issues.guix.gnu.org/57474>.
> Reported by Michael F. Lamb <mike@orbital.rodeo>.
>
> Running 'guix pull' to target current revisions would lead to memory
> exhaustion. Bumping the memory size works around that.
>
> * doc/guix.texi (Running Guix in a VM): Change "-m 1024" to "-m 2048".
>
>
> However, to quote Ludo from that bug#57474:
>> It looks like the memory requirements to build the latest revisions of
>> Guix have increased (and this is a bit ridiculous).
>
> Nevertheless the docs should mention 2GB, I guess.
>

Sounds good. I'll create a patch soon.

Toggle quote (3 lines)
>
> Regards,
> Florian
P
P
pelzflorian (Florian Pelz) wrote on 8 Dec 2022 18:02
(name . Joshua Branson)(address . jbranso@dismail.de)(address . 58357@debbugs.gnu.org)
87r0x9hlqq.fsf@pelzflorian.de
Joshua Branson <jbranso@dismail.de> writes:
Toggle quote (2 lines)
> Sounds good. I'll create a patch soon.

Is 2GB minimum a good idea? Really don’t know. Is it too late for the
release? I guess yes because string freeze
But maybe I misunderstand.

Regards,
Florian
P
P
pelzflorian (Florian Pelz) wrote on 9 Mar 2023 22:06
(name . Joshua Branson)(address . jbranso@dismail.de)(address . 58357@debbugs.gnu.org)
87r0tx4ou5.fsf@pelzflorian.de
"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes:
Toggle quote (10 lines)
> * But: Maybe the 2GB requirement should be documented after all.
>
> IIRC someone somewhere suggested treating such high RAM usage a bug
> and reducing module imports, for example, but not add a memory
> requirement to the documentation. I run a guix search and think the
> de-facto requirement is somewhere slightly above 1GB? But I guess I
> test wrongly.
>
> I’m keeping this bug open because of the RAM thing. WDYT?

Digging out this old bug, I no longer believe the RAM requirement needs
to be documented: We could document that users with little RAM should
enable swap space, but I don’t see a place where it fits. Also enabling
swap when programs crash seems like common knowledge not specific to
Guix.

Can we close? What do you think?

Regards,
Florian
P
P
pelzflorian (Florian Pelz) wrote on 20 Aug 2023 19:44
(name . Joshua Branson)(address . jbranso@dismail.de)
87cyzhr4l9.fsf@pelzflorian.de
close 58357
thanks

While Guile hackers are AFAIK slowly working towards less RAM usage when
compiling, RAM usage is close to 1GB for `guix pull` alone and is still
~1.5GB on a complete lean Sway-based operating system. But still, I
believe documenting it is not useful and this bug ticket is no longer
useful. Closing.

Regards,
Florian
?
Your comment

This issue is archived.

To comment on this conversation send an email to 58357@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 58357
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch