* Re: Guix on 32-bit x86 systems
2022-04-05 21:43 Guix on 32-bit x86 systems Andy Tai
@ 2022-04-06 20:20 ` raingloom
2022-04-12 0:23 ` raingloom
2022-04-17 1:14 ` Denis 'GNUtoo' Carikli
1 sibling, 1 reply; 4+ messages in thread
From: raingloom @ 2022-04-06 20:20 UTC (permalink / raw)
To: help-guix
On Tue, 5 Apr 2022 14:43:57 -0700
Andy Tai <atai@atai.org> wrote:
> Hi, I wonder do people recommend running Guix as the primary OS on
> 32-bit x86 systems? I have some old 32-bit 80x86 (Pentium) PCs that
> were running Fedora and of course Fedora had dropped support for
> 32-bit x86 some time ago.
>
> I am curious how would Guix work on such hardware. These old PCs may
> have memory of 4 GB or less. Would that be an issue for running Guix
> as Guix tries to build software from sources and the build process
> may not be possible on systems without much RAM. Thanks for info on
> this
>
Building large software is definitely an issue, but I think this is
basically the same problem that ARM systems have.
I managed to run a very bare bones Guix on an old Pentium II PC once,
guix pull was very slow, but the main problem was that it only had 4
gigs of storage.
You can always offload builds to a more powerful machine, or wait for
the substitute server to catch up.
Even pulling should be faster nowadays, since now we have the
channel-with-substitutes thing, or whatever it's called, so it will
only pull the channel if substitutes are available for the guix part.
Note that that does not mean they are available for whatever packages
are in your profile(s).
Also if it's a really old system, you might need to compile your own
kernel without PAE. That can take a while and it's not something you'll
want to do on an old machine if you can avoid it. Might be a good idea
to create a custom kernel config that only builds the modules you will
actually need.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Guix on 32-bit x86 systems
2022-04-05 21:43 Guix on 32-bit x86 systems Andy Tai
2022-04-06 20:20 ` raingloom
@ 2022-04-17 1:14 ` Denis 'GNUtoo' Carikli
1 sibling, 0 replies; 4+ messages in thread
From: Denis 'GNUtoo' Carikli @ 2022-04-17 1:14 UTC (permalink / raw)
To: Andy Tai; +Cc: help-guix
[-- Attachment #1: Type: text/plain, Size: 3763 bytes --]
On Tue, 5 Apr 2022 14:43:57 -0700
Andy Tai <atai@atai.org> wrote:
> Hi, I wonder do people recommend running Guix as the primary OS on
> 32-bit x86 systems? I have some old 32-bit 80x86 (Pentium) PCs that
> were running Fedora and of course Fedora had dropped support for
> 32-bit x86 some time ago.
>
> I am curious how would Guix work on such hardware. These old PCs may
> have memory of 4 GB or less. Would that be an issue for running Guix
> as Guix tries to build software from sources and the build process
> may not be possible on systems without much RAM. Thanks for info on
> this
I'm still (mostly) using Parabola i686 on my main computer.
From time to time I boot on Guix, do the updates and try to
configure more things and/or do tests and/or fix things.
When I boot on Guix, I've also a script to chroot in Parabola. So at
least I can still use software that is not packaged in Guix yet, but
I'd prefer having everything integrated like in my Parabola
installation.
And I share some configuration and the home between the two systems to
keep them in sync.
Here's the chroot script:
> #!/bin/sh
> # GPLv3+
> root="/path/to/parabola-i686/mount/directory"
> username=gnutoo
>
> for d in dev dev/pts dev/shm etc/machine-id proc sys tmp/.X11-unix ;
> do
> mount | grep " on ${root}/$d" > /dev/null || \
> mount -o bind /$d ${root}/$d
> done
>
> if [ -f ${XAUTHORITY} ] ; then
> mount | grep " on ${root}/${XAUTHORITY}" > /dev/null || \
> mount -o bind ${XAUTHORITY} ${root}/${XAUTHORITY}
> fi
>
> chroot "${root}" /bin/bash --login -c \
> "sudo XAUTHORITY=${XAUTHORITY} DISPLAY=${DISPLAY} -i -u
> ${username};"
It enables to run graphical applications, and sound probably works too
but I can't use udisksctl in that chroot yet as it expects to talk to a
deamon that is only launched in Guix.
One of the issue I found with Guix on i686 that x86_64 doesn't have is
that the per process address space is limited to 3GiB on GNU/Linux with
an i686 kernel (even with pae and 8GiB of RAM). And it's limited to
4GiB with an x86_64 kenrel and a 32bit userspace.
The issue I had with that is that rust doesn't compile yet under 3GiB
of RAM (but I managed at some point to make it compile under 4GiB with
some help of the people working on mrustc) though. So it might be
possible (with some work) to fix that to get substitute as the
substitute servers have 64bit kenrels, but yet not being able to
compile them yourself on i686.
Though for now for some applications you can remove the depedency on
rust by using the older librsvg that isn't written in rust, however gdm
won't work without rust, so now I use sddm. And some software isn't
available (like iceweasel), so I use the Parabola chroot for that, but
I mainly use it to read the Guix manual offline, so at some point I
might find another browser that is fast enough to do text search in the
complete manual.
But at the end of the day it's more other limitations that are probably
also present in the x86_64 Guix that are preventing me from using Guix
as my main operating system.
For instance right now I need to launch seatd manually in a screen
before being able to launch sway through sddm as seatd service support
has not been merged yet.
Once booted and logged and so on I can do almost everything I do in
Parabola (as I also have a Parabola chroot) but I often need extra
steps to do many of these things (like using the chroot, or doing the
network setup by hand, etc).
So my main usage of Guix is usually for other things like unit testing
/ integration testing of a library I work on, working arround software
not working or missing in Parabola i686, etc.
Denis.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread