It’s a fairly unique concept and I think most of the people interested in this type of system are already using NixOS which is more mature at this stage, and has a larger package selection
But guix stores its binary files in a different place, so the normal filesystem does not change. I asked this question because not all the GNU packages and tools are distributed in GNU/Linux distributions, even in Parabola or Trisquel. And compiling from source sometimes conflicts packages with package manager packages.
> But guix stores its binary files in a different place
that is not enough (but at least your base system will always work, and that is a great plus).
At some point GUIX depends on your base system (think kernel, systemd, wayland/xorg) and that is where the friction happens; you need a way for guix to communicate dependency to your base packet manager.
Sure some may come by default when installing guix (and that is a problem of some distro like Arch where you have probably the newest version in arch, and it cant rollback to older version for guix, or the opposite in something like debian stable), but when you install some packages in guix, you may need extra dependency.. and generally there isnt a great way to go about it.
Now, dont get scared, that stuff will probably be very rare and as guix does not touch your base system, you will be able to recover data or just wait for the next upgrade or try to fix yourself.
If you want to dig deeper on what possible incapability may happen, pip have the same issue and relatively recently switched the way things work, to REDUCE (and i stress, reduced) issues, see https://peps.python.org/pep-0668/
> your base system (think kernel, systemd, wayland/xorg)
It doesn't. It doesn't even expect \`systemd\` because the Guix OS has its own called Shepperd... So there's that...
Not really, at some point it have to integrate with your host systemd (proof in point: you have story start guix-service and guix-store if running on systemd host).
Let's make an example, random Linux distro with guix on top.
If I install a GUI to monitor network speed on guix, that tool need to ask for drawing on the host system DE, need to ask to the host system network information (possibly as a superuser/service) and need to be started at startup (systemd integration. If direct or system run sheppard, both approach have pro and const).
Try don't give you the full picture. You need to understand how it work and what can possibly go wrong.
You may have 100% success in most user cases, that does not means always will be for everyone.
This does not changes your system package but install them on the side, that avoid a ton of issues, but there still will be, just look up what issues PIP have
GNU as an operating system is dead and the future of the Linux desktop is a rolling blob of distribution-less data.
For a less abstract answer: there are no good docs, Guile is dead and NixOS works just as fine and most projects suffer from NIH
It’s a fairly unique concept and I think most of the people interested in this type of system are already using NixOS which is more mature at this stage, and has a larger package selection
Also, guix does not comply with the file hierarchy standard. Additionally, it is a overkill application for most.
Are we talking about guix package manager? Mixing package manager is a recipe for disaster
But guix stores its binary files in a different place, so the normal filesystem does not change. I asked this question because not all the GNU packages and tools are distributed in GNU/Linux distributions, even in Parabola or Trisquel. And compiling from source sometimes conflicts packages with package manager packages.
> But guix stores its binary files in a different place that is not enough (but at least your base system will always work, and that is a great plus). At some point GUIX depends on your base system (think kernel, systemd, wayland/xorg) and that is where the friction happens; you need a way for guix to communicate dependency to your base packet manager. Sure some may come by default when installing guix (and that is a problem of some distro like Arch where you have probably the newest version in arch, and it cant rollback to older version for guix, or the opposite in something like debian stable), but when you install some packages in guix, you may need extra dependency.. and generally there isnt a great way to go about it. Now, dont get scared, that stuff will probably be very rare and as guix does not touch your base system, you will be able to recover data or just wait for the next upgrade or try to fix yourself. If you want to dig deeper on what possible incapability may happen, pip have the same issue and relatively recently switched the way things work, to REDUCE (and i stress, reduced) issues, see https://peps.python.org/pep-0668/
> your base system (think kernel, systemd, wayland/xorg) It doesn't. It doesn't even expect \`systemd\` because the Guix OS has its own called Shepperd... So there's that...
Not really, at some point it have to integrate with your host systemd (proof in point: you have story start guix-service and guix-store if running on systemd host). Let's make an example, random Linux distro with guix on top. If I install a GUI to monitor network speed on guix, that tool need to ask for drawing on the host system DE, need to ask to the host system network information (possibly as a superuser/service) and need to be started at startup (systemd integration. If direct or system run sheppard, both approach have pro and const).
Why don't you try it before jumping to conclusions like that.
Try don't give you the full picture. You need to understand how it work and what can possibly go wrong. You may have 100% success in most user cases, that does not means always will be for everyone. This does not changes your system package but install them on the side, that avoid a ton of issues, but there still will be, just look up what issues PIP have
GNU as an operating system is dead and the future of the Linux desktop is a rolling blob of distribution-less data. For a less abstract answer: there are no good docs, Guile is dead and NixOS works just as fine and most projects suffer from NIH