Message ID | 20221007142445.25162-1-jbranso@dismail.de |
---|---|
State | New |
Headers | show |
Series | [bug#58357,staging] doc add a recommended system in 'Hardware Considerations' | expand |
Context | Check | Description |
---|---|---|
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/applying patch | fail | |
cbaines/issue | success | View issue |
cbaines/comparison | success | View comparision |
cbaines/git-branch | success | View Git branch |
cbaines/applying patch | success | View Laminar job |
cbaines/issue | success | View issue |
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
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
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
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’.
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) --
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
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
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
"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
"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
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’.
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’.
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
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
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
"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
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
"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
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
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