[HN Gopher] Hacking anything with GNU Guix
___________________________________________________________________
Hacking anything with GNU Guix
Author : podiki
Score : 224 points
Date : 2022-09-21 15:47 UTC (7 hours ago)
(HTM) web link (gexp.no)
(TXT) w3m dump (gexp.no)
| davexunit wrote:
| 'guix shell' is killer. I use it for all my projects and one-off
| experiments. I also hook it up to Emacs 'M-x compile' so that
| compilation happens in the context of the guix shell. Beyond the
| simple command line package specification, you can add a guix.scm
| file to the root of your project repo and fill it with code that
| specifies all the packages needed for a development environment.
| Some of my guix.scm files are simple lists of existing packages,
| others are full of custom code to modify existing packages or
| define new ones. No matter how simple or complex it is behind the
| scenes, I just run 'guix shell' and get on with working on my
| project.
| daptaq wrote:
| You might be interested in buffer-env, it can automatically
| load an environment on a buffer-to-buffer basis and make it
| appear as though it were globally installed. No manual "guix
| shell ... -- ..." calls needed.
| davexunit wrote:
| Thanks, I've been meaning to check it out, so long as I can
| integrate guix shell with it.
| dman wrote:
| Could you elaborate a bit on how this works? Am a longtime
| emacs user and very motivated to get this working!
| dman wrote:
| Any pointers to your setup?
| genpfault wrote:
| ...except KDE[1]:
|
| > GNOME, Xfce, LXDE, and Enlightenment are available (see Desktop
| Services), as well as a number of X11 window managers. However,
| KDE is currently missing.
|
| [1]: https://guix.gnu.org/manual/en/html_node/Limitations.html
| bogwog wrote:
| I had an idea recently to try out Fedora silverblue with Guix on
| top.
|
| Silverblue gives you an immutable root filesystem, which is great
| for building a reliable and reproducible system, but it makes
| installing software more complicated. Containers are the main
| solution, and stuff like flatpaks and toolbox. That (mostly)
| works, but it's a bit heavy handed and not without annoyances.
|
| But with guix, your packages live in the guix store, and don't
| touch your os packages. So that seems like a good way to manage
| software on top of an immutable OS.
|
| Unfortunately when I went to try it out, I learned that the only
| way to change the default location of the guix store (since
| /gnu/store won't work in silverblue, and Guix isn't available as
| a package for fedora) is to build it from source... and then I
| ran into some build issues when trying to do that and gave up.
|
| ...So maybe someone less lazy than I will pull it off and report
| back whether it's actually a good idea or not!
| Infernal wrote:
| I'm downloading the silverblue iso right now to play with this
| in a VM. It is surprising to me that ostree does not let you do
| any sort of bind mount or symlink of a non-reserved location
| like /gnu to some other filesystem, so I'll have a whack at it.
| bogwog wrote:
| > It is surprising to me that ostree does not let you do any
| sort of bind mount or symlink of a non-reserved location like
| /gnu to some other filesystem, so I'll have a whack at it.
|
| ...Well, it might. I actually had zero experience with both
| ostree/silverblue and guix when I tried doing this, and may
| have made some hasty assumptions.
|
| EDIT: I do know however that guix doesn't work if the store
| is a symlink. I tried doing that a while back and it didn't
| work.
| Infernal wrote:
| So you can create /gnu/store on Silverblue with the commands
| (as root) chattr -i / mkdir -p
| /gnu/store chattr +i /
|
| The last command restores the immutable attribute on the root
| filesystem. I am able to write arbitrary files (e.g. `touch
| /gnu/store/test`) even with that attribute set, so it isn't
| inherited by subdirectories (maybe obvious).
|
| Now, persistence of the /gnu/store data could be an issue,
| I'm not sure, but maybe this gets you started?
|
| EDIT: next step is to get Guix installed and then try to
| update the system, we shall see how it goes
| Infernal wrote:
| So, having removed the immutable attribute from / and run
| the guix-install.sh script, the first issue I have is that
| the script thinks the group 'kvm' exists, because 'getent
| group kvm' returns successfully. However, if you try to
| create a user and add them to the kvm group, you get an
| error about the group not existing. Looking at the contents
| of /etc/group, there are only 5 groups and none of them are
| 'kvm'. At the very least it seems that the Guix install
| script is making some assumptions about the system that
| Silverblue breaks, which does make me wonder a bit about
| using the two side by side.
|
| Additionally, I have found some posts as far back as 2017
| regarding using Guix or Nix on Fedora Atomic Linux or
| Fedora Container Linux (it seems the Silverblue name is
| more recent) and the fact that we're still puzzling it out
| 5 years later without much in the way of documented success
| does make me question the viability of the idea a bit.
| bogwog wrote:
| I just tried doing that to create the bind mount at
| /gnu/store via fstab, and it disappeared on reboot (and
| threw me into an emergency console). Removing the fstab
| line allowed me to boot normally again.
|
| I think the solution will require using systemd to recreate
| that folder on boot, and do it early enough to not make the
| system panic like that.
|
| Maybe that's a bad idea, I don't know enough about
| ostree/silverblue. However, after some more digging it
| seems like this solution would be preferable to changing
| the default guix store with a custom build, since doing
| that means you can't use any of the pre-compiled binary
| packages from the official guix servers.
| yjftsjthsd-h wrote:
| Wouldn't that require that the mountpoint exists in the
| underlying filesystem? That is, you can't create a /gnu
| directory to mount into if root is read-only
|
| EDIT: Or is the filesystem not literally read-only? Sibling
| comment seems to imply that it's just chattr +I'd
| bogwog wrote:
| I just tried it, and the folder created via chattr
| disappered after rebooting. So it seems like there's more
| to it.
| colordrops wrote:
| What does silverblue give you on top of what Guix and Nix
| already provide?
| bogwog wrote:
| In Guix's case, a working desktop with wayland + proprietary
| Nvidia drivers. (I'm actually using Kinoite, which is the KDE
| spin of silverblue)
|
| I could install Guix on top of something like Ubuntu or
| Fedora workstation for the same effect, but then I'll have
| two system package managers side by side, which is pointless
| and probably error prone.
| von_lohengramm wrote:
| You can do that with NixOS trivially.
| rekado wrote:
| And of course with Guix System. (odd to always see Nix*
| mentioned when someone talks about Guix.)
| striking wrote:
| Comparing https://wiki.systemcrafters.cc/guix/nvidia/
| with https://nixos.wiki/wiki/Nvidia makes me think that
| in _this specific case_ there 's a difference.
| pxc wrote:
| A question for nonguix contributors, including OP: is
| there a reason that nonguix has an nvidia package but not
| an nvidia service that handles more of this in a
| streamlined way, even just some stuff copied and pasted
| from this wiki?
| RaitoBezarius wrote:
| Well, Guix is also mentioned when someone talks about
| Nix, seems fair to me (and of course, Guix may be more
| relevant sometimes!).
| pxc wrote:
| An FHS base system that still gives you some the nice
| features of Nix and Guix, like immutability and rollbacks.
|
| In theory something like it could be a giant escape hatch so
| that if you run into Guix packaging difficulties for some
| software that, e.g., tries to fetch from the internet at
| runtime, you can just build with autoconf and make.
| Silverblue might be quirky enough that it has its own hiccups
| though, idk.
| podiki wrote:
| Not on Silverblue but I've used a bindmount to have /gnu/store
| elsewhere (due to disk space on a laptop). I can dig up some
| notes if that is helpful.
| bogwog wrote:
| I didn't think to try doing a bind mount, so that might
| actually work. I'll need to try it again at some point!
| pca006132 wrote:
| Not sure about guix, but for nixos we have
| https://github.com/nix-community/nix-user-chroot
| [deleted]
| [deleted]
| kqbx wrote:
| > PYTHONPATH, CPATH, etc are all set up and ready to go.
|
| Does that mean that Guix just exports the required environment
| variables in the shell rather than wrapping each executable with
| a bash script [1] like nix does?
|
| If yes, that's great, because the wrapper approach feels like an
| ugly hack. I found some executables on my nixos installation that
| are behind _three_ layers of wrappers, and that 's probably not
| the maximum.
|
| I guess nix could improve this situation by making `wrapProgram`
| smarter (if the executable to be wrapped is already a wrapper,
| merge the inner and outer wrapper), but even single-layer
| wrappers are annoying, and I imagine they have some performance
| impact.
|
| EDIT:
|
| I forgot about nix-shell, which does actually export the right
| environment variables directly to the shell.
|
| [1] https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-
| supp...
| pxc wrote:
| Does nix-shell/`nix develop` use makeWrapper?
| kqbx wrote:
| Thank you, I totally forgot how nix-shell works. You're
| right, it should export the right env variables without
| makeWrapper.
|
| I haven't used nixos in a while and I got confused about this
| because to install python packages _globally_ I used
| `python3.withPackages` and that does use the wrappers.
| yyyk2 wrote:
| Guix has a mechanism called search-paths which is defined for
| any package like Python that searches for things based on
| envars; it exports the relevant search paths into the
| environment. Though it also has shell wrappers, which are
| essentially a hack around non-propagating dependencies: it
| allows you to expose things that would normally be visible to
| everyone, like executables, to just the specific program.
| zelphirkalt wrote:
| Plus: You can make it all reproducible using `guix time-machine`.
| hedora wrote:
| Can anyone comment on how this compares to apt-get source?
| (Optionally run inside docker?)
| daptaq wrote:
| AFAIK that won't install all the necessary dependencies, right?
| And even if it does, these are installed globally. Guix shell
| will only make the dependencies visible while the shell is
| active, and "hide" them again as soon as the process
| terminates.
| pxc wrote:
| It's more like `apt build-dep`, but you don't install all the
| development libraries and headers to your system in a global,
| persistent way. Instead you just make them available for that
| shell session.
|
| It's likely a lot smaller than a Docker container that contains
| a whole Ubuntu runtime, and it'll automatically share a cache
| of deoendencies with any Guix packaged you may have installed
| locally. It also has normal/native access to your filesystem
| (and thus your dotfiles and your homedir), since it doesn't
| live in a container.
| podiki wrote:
| Not an apt user but my quick search suggests this just
| downloads the source of the package? The guix shell
| --development command in this article is for getting all the
| dependencies needed to build the package (but not the source
| itself, though you can do that through other guix commands I
| believe). In other words, with guix shell you can now run make
| or whatever you need to build the package in question, without
| needing to fetch the development tools, other libraries, set
| env variables, etc.
|
| Edit: for the source of a package guix build --source
| thepackage will return the path to the source (as stored in the
| store). This includes any patches or transformations (e.g. you
| can pass patches to be included or a git/branch/commit location
| to pull the source from instead of what is defined in the
| package definition)
| pizza wrote:
| The article is about having the correct environment set up -
| attacking the problem from the environment level.
|
| When I think of "hacking code you didn't write" one of the
| biggest hurdles for me is "inserting my changes to the behavior
| of the code with minimal refactoring of the original" - attacking
| the problem from, perhaps, compiler instrumentation level.
|
| e.g. suppose when I use some library function f, there is a
| deeply nested function, g, that has access to some data x, which
| is cleaned up somewhere before the API returns its result.
|
| How do I tell my compiler "I want a new function h, which, when
| given the same arguments as f, returns x, by returning from
| within g" ?
| LanternLight83 wrote:
| This problem is trivial within emacs thanks to the advice
| system, and something I've always missed in literally any other
| programming environment. In Guile, I bet `(parameterize)` could
| be used to similar ends, but you don't get to choose the
| language of every project you hack on.
| retzkek wrote:
| It should be pointed out that "guix shell" is currently only
| available in the unstable "latest" version, not the stable
| "standard" release (v1.3.0). If you are running an older version,
| "guix environment" is similar.
|
| https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix...
|
| https://guix.gnu.org/en/manual/en/html_node/Invoking-guix-en...
| podiki wrote:
| Another great use of guix shell that I tend to do is for one off
| commands. I don't need OBS installed to use it occasionally, I
| can just do "guix shell obs -- obs" to run it once and not have
| it in my PATH, application launcher, etc. when I don't need it.
| Or better yet for running python or CL scripts, with something
| like 'guix shell python [python packages] -- python3 myscript.py
| "some argument"'. No need to carry around these libraries. This
| can be done with a manifest or guix.scm file as well, that guix
| shell will use automatically (once authorized, so you don't
| accidentally run something).
|
| This keeps things tidy in terms of just having packages I need
| all the time installed, while still being very quick after the
| first run. (There are some caveats about garbage collection, but
| I rarely do that.)
|
| And as the article mentioned there's also containers...lots of
| useful tools.
| chubot wrote:
| I had a couple people attempt this for the dev environment of
| https://www.oilshell.org/ with Nix, and it wasn't entirely
| successful. (Not Guix, but my understanding is that Guix would
| have the same issues)
|
| As background, we've long had a set of evolving shell scripts
| that fetch and build dependencies at specific versions -- like
| bash/dash/zsh/mksh/busybox to test against, re2c to generate
| code, CommonMark, Python 3.10, MyPy with pip dependencies, and
| (bonus) R with CRAN dependencies.
|
| I wrote about 2 problems here:
| https://lobste.rs/s/s5co2f/where_contributors_have_problems_...
|
| 1. OS X and libc, which is not really a problem since our
| existing scripts don't solve it either. It was just one
| motivation for Nix that didn't quite work out.
|
| 2. The file system layout becomes different, and Oil's shell
| tests rely on that. So containers ended up being easier. The
| whole build and test system runs in OCI containers under Docker
| and podman now, so it's pretty reproducible and automated.
|
| But I still think it would be nice if someone who actually knows
| Nix and Guix (unlike me) tries again. The dependencies are more
| stable now than 2 years ago.
|
| I think you have to write like 10 Nix or Guix expressions from
| scratch with the exact tarballs that we use. (Otherwise the tests
| will break even more, because Oil's tests are extremely detailed
| and find bugs in specific versions of specific shells.)
|
| Right now we have a 134 line shell.nix that tries to reuse Oil's
| scripts, but I think it doesn't gibe with the way that Nix and
| Guix are meant to be used. Probably the real solution would be
| more like 1000 lines from scratch?
|
| I remember that Nix Flakes was what I thought Nix was going to
| be, but at the time it wasn't ready. I thought Nix was supposed
| to solve the "it works on my machine" problem but it actually
| doesn't -- you still need a CI because it's possible to write
| .nix expressions in ways that break the sandboxing (unlike Bazel
| where you always get it).
|
| I had ran this by someone who knows Guix and my takeaway was that
| Guix is basically the same in that regard.
|
| A key problem is that, at least for awhile, I want it to work in
| parallel with our existing system ... not have a "big break".
| smasher164 wrote:
| As long as you don't hardcode "expected paths" (like in the
| FHS) in the filesystem, and expose the expectations you have
| via some configuration (environment variables and flags are
| fine), then packaging your software for Nix is pretty
| straightforward.
| pxc wrote:
| > But I believe libc is fundamentally a "hole" in the
| sandboxing of Nix, at least on OS X.
|
| Nix doesn't sandbox builds on macOS at all by default, and
| turning sandboxing on breaks some builds:
| https://github.com/NixOS/nix/pull/1821
|
| But the libc issue goes deeper. This blog post has some
| explanation: https://matthewbauer.us/blog/darwin-stdenv-
| update.html
|
| > Linux is unique among operating systems due to the fact that
| the Kernel and Libc are developed independently. Linux is
| maintained by creator Linus Torvalds and a community of
| contributors. Glibc, the most popular Libc for Linux, is
| maintained by the GNU project. As a result, Linux has a strong
| separation between Syscalls and Libc.
|
| > [ ... ]
|
| > To accomplish this, Linux provides a stable list of syscalls
| that it has maintained across many versions. This is specified
| for i386 at arch/x86/entry/syscalls/syscall_32.tbl in the
| kernel tree. The syscalls specified here are the interface
| through which the Libc communicates with the kernel. As a
| result, applications built in 1992 can run on a modern kernel,
| provided it comes with copies of all its libraries.
|
| > The macOS Libc is called libSystem. It is available on all
| macOS systems at /usr/lib/libSystem.B.dylib. This library is
| the main interface that binary compatibility is maintained in
| macOS. Unlike Linux, macOS maintains a stable interface in
| libSystem that all executables are expected to link to. This
| interface is guaranteed by Apple to be stable between versions.
|
| > In Nixpkgs, we maintain this compatibility through a list of
| symbols that are exported by libSystem. This is a simple text
| list and is available for viewing at NixOS/nixpkgs/pkgs/os-
| specific/darwin/apple-source-
| releases/Libsystem/system_c_symbols. The symbol list is created
| by listing symbols (nm) on the minimum macOS version that we
| support (for my PR, 10.12). We do some linking tricks to ensure
| that everything that we build in Nixpkgs only contains those
| symbols. This means that we can reproducibly build on newer
| versions of macOS, while maintaining compatibility with older
| macOS versions. Unfortunately, newer symbols introduced in
| later versions cannot be used even on systems that have those
| symbols.
|
| > A side effect of macOS design, is that fully static
| executables are not supported in macOS as they are on Linux.
| _Without a stable syscall interface, there is nothing to
| provide compatibility between versions._ As a result, Apple
| does not support this type of linking.
|
| So Nixpkgs does do some things to try to let you peg builds
| only to what's available in older versions of the macOS libc,
| but it doesn't try to let you bring your own libc.
|
| There's at least one libc that does claim this kind of
| portability of course, and is the subject of lots of good posts
| here on HN. Maybe the author of Cosmopolitan libc (
| https://justine.lol/cosmopolitan/index.html ) might have
| something insightful to say here.
| chubot wrote:
| Also, reading back on that, I think the hardest part would be
| "PyPI dependencies" of MyPy, and "CRAN dependencies of R
| scripts like dplyr". These have what I call the "rewriting
| upstream" problem.
|
| Though maybe a hybrid approach can work? Or does that defeat
| the purpose? I think a problem with these kinds of systems is
| that they can be "all or nothing". If you're halfway in, and
| halfway out, you don't get any benefits.
| pxc wrote:
| For lang-specific package managers that have a lockfile
| format, it's possible to write tooling that lets you run
| `cargo lock` or whatever and then generate the required Nix
| expressions for those dependencies. For stuff that doesn't
| support such a format, if you had your scripts export to your
| own little json lockfile format, you could have Nix read that
| (Nix expressions can ingest json).
|
| There's some ongoing work to better support 'generating'
| those Nix expressions and using them in builds without
| explicitly storing them anywhere, as well (John Ericson's
| RFCs on 'import-from-derivation' and related functionality),
| and for unifying such tooling (dream2nix). (This kind of
| thing is what the `guix import` CLI does, but it has some
| limitations.)
|
| There's some talk of possibly using Oil Shell for a port of
| Nixpkgs to Windows, although another language might be chosen
| by whoever really takes up that work. People interested in
| adding native Windows support to Nix might be interested in
| helping you sort out Nix packaging for Oil (I see there is a
| package currently, but it's not a source build).
| rank0 wrote:
| Can anyone explain to me the appeal of guix over nix? Is the
| learning curve any easier? I really badly wanted to like
| nix...but its just so strange and unconventional.
|
| Whenever I need a disposable environment I reach for lxc/lxd.
| pxc wrote:
| Guix is strange and unconventional in the same fundamental way
| as Nix, namely that each package is installed to its own,
| immutable, quasi-content-addressed prefix. This is because that
| design decision is what gives both package managers their
| superpowers.
|
| If you are already a Scheme user, you may find Guix more
| accessible for you. If you are not a C++ programmer, you may
| find hacking on the package manager itself easier with Guix.
|
| In terms of the CLI interface, Guix really shines here. Guix
| also has a more centralized approach to documentation, which
| you may find helpful.
|
| Beyond the surface-level language differences, Guix has gone
| with different abstractions than Nix in some key areas, and has
| some features that Nix lacks. One big one is that GuixSD uses a
| different model for defining the options that can be used to
| configure the system. Guix's approach1 is more explicit, and
| features some provenance tracking for configured options-- it
| can draw a graph for you showing where each setting on your
| system came from.
|
| Guix also takes a different approach to pinning package
| versions and defining repositories of source packages, and its
| conventions for doing those things are more settled than their
| equivalents and alternatives in the Nix world.
|
| Guix also supports a feature called 'grafts'2 that allows you
| to avoid rebuilding the world in case of things like mission-
| critical security updates to glibc. This is a really cool and
| useful feature!
|
| I'm sure there are other things that more serious Guix users
| can better highlight than this dilettante. :)
|
| The Guix blog is really excellent! I strongly recommend it for
| getting a sense of what problems Guix tries to solve and how it
| sometimes approaches them differently than Nix does.
|
| --
|
| 1: https://guix.gnu.org/manual/en/html_node/Defining-
| Services.h...
|
| 2: https://guix.gnu.org/blog/2020/grafts-continued/
| Macha wrote:
| I tried and bounced off Nix on other systems, and I'm now
| running nixOS on my personal laptop (which is a secondary
| device).
|
| I think there's absolutely room to solve the same set of
| problems better than Nix does:
|
| 1. The number 1 problem for me has been documentation of
| nixpkgs. Nix lang is a bit funky but even if I was writing
| python the problem is that you're writing code to assign
| magic objects to magic variables and the only way to find the
| right ones is to read the nixpkgs source (and given the size
| of all-packages.nix and the limit of github's web viewer,
| maintain a local checkout).
|
| 2. Second place goes to the flake/non-flake divide where the
| nix community generally implies flakes are better but apart
| from the nix cli detailed docs, most things refuse to
| acknowledge its existence in the official docs.
|
| 3. Portability between macOS and Linux, where flakes actually
| make the situation worse as the root config is now system
| specific.
|
| 4. Tools like flakes, niv, the suggested way to write a
| shell.nix all want you to handle full commit hashes directly
| which is kinda unergonomic.
|
| None of these are inherent to the problem space. If I was to
| keep writing the list, maybe around 9 and 10 are the things
| around nixlang being a funky language or /nix directory that
| the "you just need to understand functional languages/content
| addressable stores" discussion seems to think are the top
| ones.
| pxc wrote:
| Agreed on points 1 and 2. I think 3 is basically solvable
| for Nix, and it's easy to paper over with a Nix library for
| now.
|
| Re: 4, Flakes do let you define inputs in terms of Git tags
| and branches and then have the computer resolve those to
| commit hashes for you, which is good.
|
| Overall, I agree that it's not fair to think of package
| managers that work in the same basic paradigm as Nix as
| mere also-rans or clones. There's a lot of room to
| meaningfully experiment in the space and Guix's developers
| have proven thoughtful about where they want to differ in
| technical and ergonomic matters.
| nitsky wrote:
| What in particular did you find strange and unconventional?
| im3w1l wrote:
| For me it was the core premise that is both the blessing and
| the curse. That it is only possible to install software by
| first packaging it.
| amelius wrote:
| That's because the basic idea is immutability and that
| doesn't go well with OSes designed around mutability.
|
| Nix/Guix are basically the "glue" that connects two worlds.
| jolmg wrote:
| Haven't tried guix yet, and haven't used nix in years, but if
| what you struggled with is the language, guix might be less
| strange and more conventional since it uses Scheme as the
| language. It uses strict evaluation like most languages and
| there's probably more documentation about it.
| amelius wrote:
| I think the main difference is that Guix will only support open
| software officially, whereas Nix will also happily allow
| proprietary stuff, like nVidia drivers.
|
| See e.g.:
|
| https://gitlab.com/nonguix/nonguix
|
| > Guix channel for packages that can't be included upstream.
| Please do NOT promote or refer to this repository on any
| official Guix communication channels.
| medstrom wrote:
| Far from the 'main difference' -- if there was a project that
| just forked Nix and made that change, you could say that
| about it, but not about Guix, which has tons of work-hours
| invested and pretty much none of those work hours have to do
| with that.
| amelius wrote:
| True but that's from mostly a technical perspective. It is
| also (more?) important to know how a community thinks.
| turboponyy wrote:
| From what I can tell (I've only used NixOS/Nix), Guix has
| considerably more thought put into the UX: Nix is currently
| undergoing a transition to a newer CLI; Nix's nomenclature is
| confusing; Guix has much better documentation; Guix has its
| equivalent of Nix's home-manager built-in.
|
| There is still some division in the Nix ecosystem between the
| pre-flake and the experimental post-flake way of doing things.
|
| Guix uses an established programming language for
| configuration, which some might find attractive (I actually
| quite like Nixlang after getting used to it).
|
| Guix makes installing non-free software a hassle (you have to
| include community sources). Nixpkgs doesn't impose this
| restriction, though you still have to explicitly allow the
| install of non-free packages when running Nix.
|
| Overall, Guix seems like the more polished product, though
| NixOS/Nix is similar in functionality and has a larger
| collection of packages and more traction in general.
| openfuture wrote:
| I think that allow unfree in nix is practically the same as
| adding nonguix repo to your channels. Both are essentially
| one line of config in some file.
|
| (I am former nixos user but now on guix)
| retzkek wrote:
| > Overall, Guix seems like the more polished product
|
| Possibly when comparing the Guix vs. Nix package managers,
| but for Linux distributions GuixSD ("Guix System" now) is
| very far behind NixOS in this regard. I've tried to install
| GuixSD on different hardware several times over the past
| couple years, and failed every time, between a lack of
| drivers and unpolished or buggy installer. Last time the
| installer wiped out my partition table without prompting when
| I went in to manually partition (to set up dual boot).
|
| NixOS on the other hand has always been flawless to install,
| and now there's even a modern GUI installer.
|
| I like Guix better in theory, but Nix wins in practicality.
| throw10920 wrote:
| In addition to the other answers here: the Guix repositories
| only accept Free Software, even excluding things like Firefox,
| and intentionally make it somewhat difficult to install non-
| Free-Software (as opposed to Nix, where installing things like
| Firefox is relatively easy[1]). This may appeal to some people.
|
| [1] https://nixos.wiki/wiki/Firefox
| yyyk2 wrote:
| Guix does not make non-free software "intentionally more
| difficult", it just excludes it from the main repository.
| There is a nonfree repo that you can add to your guix
| channels.
| slim wrote:
| the non free repo explicitly asks you not to talk about it
|
| https://gitlab.com/nonguix/nonguix
|
| looks intentional to me
| [deleted]
| yyyk2 wrote:
| Well, all it says that you shouldn't promote it on the
| "official channels" (i.e. the mailing list and the #guix
| libera.chat channel). Guix, the package manager itself,
| does not make installing non-free packages any more
| difficult than free packages. I suppose it could be said
| that Guix (the project) makes finding non-free packages
| harder, although anecdotally I will say that nonguix is
| the first thing I've heard about guix, since it seems to
| be the most controversial part of it.
| daptaq wrote:
| Non-free software is just off-topic in official channels,
| there is no need to interpret malicious intent into it.
| It is no more difficult to enable nonguix than it is to
| enable any other repository.
| striking wrote:
| I don't think anyone was implying malice, just that there
| was intent. Nothing wrong with having principles.
| amelius wrote:
| Reminds me of the VHS vs Betamax war, where VHS won because
| Betamax (Sony) didn't allow adult videos (at least, so the
| legend goes).
| forevernoob wrote:
| One of my personal pet peeves are that Guix does not support
| Apple, while Nix does.
___________________________________________________________________
(page generated 2022-09-21 23:00 UTC)