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

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

[Joshua Branson via Guix-patches via]

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(+)

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

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

[pelzflorian (Florian Pelz)]

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

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

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

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

[jbranso--- via Guix-patches via]

October 8, 2022 5:56 AM, "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> wrote:

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

https://wiki.parabola.nu/Computers

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

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

> 
>> +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  ?

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

> Regards,
> Florian

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

[pelzflorian (Florian Pelz)]

jbranso@dismail.de writes:
> 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.

> 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

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


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


> 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

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

[Ludovic Courtès]

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

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

[kiasoc5 via Guix-patches via]

On Fri, Oct 14 2022, 05:12:59 PM +0200
Ludovic Courtès <ludo@gnu.org> wrote:

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

-- 

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

[pelzflorian (Florian Pelz)]

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.

Regards,
Florian

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

[pelzflorian (Florian Pelz)]

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes:
> 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

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

[pelzflorian (Florian Pelz)]

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.

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.


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


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

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

[pelzflorian (Florian Pelz)]

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes:
> 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

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

[Ludovic Courtès]

Hi,

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

> 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
     <https://blog.einval.com/2022/04/19>.

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

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

[jbranso--- via Guix-patches via]

October 14, 2022 1:10 PM, "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> wrote:

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

https://www.openbsd.org/arm64.html  as an example.

Joshua

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

[Ludovic Courtès]

Hi,

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

>   • 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:

  https://issues.guix.gnu.org/59003

Feedback welcome!

Ludo’.

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

[pelzflorian (Florian Pelz)]

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?

Regards,
Florian

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

[jbranso--- via Guix-patches via]

November 15, 2022 7:23 PM, "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> wrote:

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

> 
> Regards,
> Florian

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

[pelzflorian (Florian Pelz)]

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.

Regards,
Florian

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

[Joshua Branson via Guix-patches via]

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

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

>
> Regards,
> Florian

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

[pelzflorian (Florian Pelz)]

Joshua Branson <jbranso@dismail.de> writes:
> 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
<https://lists.gnu.org/archive/html/guix-devel/2022-12/msg00076.html>.
But maybe I misunderstand.

Regards,
Florian

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

[pelzflorian (Florian Pelz)]

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes:
> * 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

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

[pelzflorian (Florian Pelz)]

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