Guix: Unifying provisioning, deployment, and management in the age of containers(archive.fosdem.org)
archive.fosdem.org
Guix: Unifying provisioning, deployment, and management in the age of containers
https://archive.fosdem.org/2020/schedule/event/guix/
74 comments
Guix use Scheme/Guile. It's way saner that the Nix custom language. The biggest pro/cons is that they are flexible dynamic languages. So when you define your deployment, you need to code very defensively because no type system will support you and find mistakes.
There's a lot of bashing of Nix language, but frankly I don't think Nix really is a problem. The language is fairly simple.
What might throw people off is that it is functional (which applies to Scheme/Guile as well).
I think the biggest problem of Nix is that the area it covers is so vast and because of that it is suffering from not having enough people working on it, which also affects the quality of the documentation. I don't know where Guix is in this area.
Regarding the language being dynamic, I recently found that there's work on making a typed language: https://github.com/tweag/nickel
Perhaps it can solve this problem.
What might throw people off is that it is functional (which applies to Scheme/Guile as well).
I think the biggest problem of Nix is that the area it covers is so vast and because of that it is suffering from not having enough people working on it, which also affects the quality of the documentation. I don't know where Guix is in this area.
Regarding the language being dynamic, I recently found that there's work on making a typed language: https://github.com/tweag/nickel
Perhaps it can solve this problem.
I agree with you.
When I got into Nix and Guix I tried both and I leaned towards Guix because "it's scheme" but ended up sticking to Nix because of maturity, Darwing support and it being way more performant.
In the end I realized that I actually prefer Nix as a language. I like that it's a very simple and limited language, with, for example, no way of performing side-effects. It is tailored towards it's purpose and, while not perfect, it does the job well.
As other point out, Nixpkgs and the Nix toolchain in general just uses very weird names for everything, plus the docs. That's the difficult bit. It's slightly improving over time.
When I got into Nix and Guix I tried both and I leaned towards Guix because "it's scheme" but ended up sticking to Nix because of maturity, Darwing support and it being way more performant.
In the end I realized that I actually prefer Nix as a language. I like that it's a very simple and limited language, with, for example, no way of performing side-effects. It is tailored towards it's purpose and, while not perfect, it does the job well.
As other point out, Nixpkgs and the Nix toolchain in general just uses very weird names for everything, plus the docs. That's the difficult bit. It's slightly improving over time.
I don't see that Nix would be more widespread if it used (say) JavaScript instead of Nix-lang for its expressions.
When you face problems, I'm sure it's more likely that you won't know how to do it with NixOS/Nixpkgs, rather than you'll know exactly what needs to be done but don't know how to express it in Nix-lang.
When you face problems, I'm sure it's more likely that you won't know how to do it with NixOS/Nixpkgs, rather than you'll know exactly what needs to be done but don't know how to express it in Nix-lang.
I program in a half-dozen common languages and read ten more, and have been doing so for decades and the Nix DSL still confuses me. I would not say it is fairly simple.
Perhaps this will change with more doc reading, but it is anything but intuitive (coming from a C, Perl, Java, JS, PHP, Python, Go, et c background).
Perhaps this will change with more doc reading, but it is anything but intuitive (coming from a C, Perl, Java, JS, PHP, Python, Go, et c background).
Those are all the same language, that are different dialects of each other. Conceptually they are all very similar, and once you know one well, you understand %90 of the other ones. Java, C & Golang are the only ones that are bit different with static typing, manual memory management (C) and language level concurrency.
Nix DSL, Haskell, OCaml, declarative UI libraries, Rx and other declarative paradigms are fairly different and do require a bit of new learning. They go way beyond functional programing basics like map and filter.
Nix DSL, Haskell, OCaml, declarative UI libraries, Rx and other declarative paradigms are fairly different and do require a bit of new learning. They go way beyond functional programing basics like map and filter.
I can't disagree more. All of the languages you have listed are well known for having complex semantics. This is totally expected of any general purpose programming language, of course. But the Nix expression language, though Turing-complete, isn't meant to be a general purpose programming language. It's a configuration DSL for defining packages. As such, it has a much smaller feature set with fewer confusing semantics.
The Nix expression language is in essence just JSON with functions comprising of the following building blocks:
* Primitive values (strings, numbers, paths, booleans, null)
* Lists and sets
* Variables
* Functions
* Conditionals
* Assertions
* Arithmetic operators
And that's basically it. All of this is succinctly explained in the official documentation[1].
[1]: https://nixos.org/manual/nix/stable/#ch-expression-language
The Nix expression language is in essence just JSON with functions comprising of the following building blocks:
* Primitive values (strings, numbers, paths, booleans, null)
* Lists and sets
* Variables
* Functions
* Conditionals
* Assertions
* Arithmetic operators
And that's basically it. All of this is succinctly explained in the official documentation[1].
[1]: https://nixos.org/manual/nix/stable/#ch-expression-language
Bazel has starlark, which is reduced python, which I've found in practice fairly easy to understand. Do you think the nix DSL could of been replaced with bazel's model of doing things and would meet the same functionality? I'm not very familiar with nix.
With some Haskell knowledge, it is much easier to grasp.
I'm not familiar with the Nix language, but GP said:
> What might throw people off is that it is functional
None of the languages you list are functional, so that could still explain it.
> What might throw people off is that it is functional
None of the languages you list are functional, so that could still explain it.
For me it's an issue primarily with syntax; I am aware of FP concepts and can recognize and understand their use.
I'm still sort of confused why it needed its own DSL and couldn't have just reused an existing language.
I'm still sort of confused why it needed its own DSL and couldn't have just reused an existing language.
Other languages were deemed too big, especially in 2003 when Nix was started. Nix is a strict diet. Perhaps something else could be used, but I can assure you Nixpkgs would be a completely failed experiment drowning in its own complexity if there were side effects.
Also, I don't understand how people can say the semantics is fine but the syntax is challenging. Syntax is entirely superficial. And if you are having trouble reading the syntax, how can you be sure the semantics isn't challenging?
There are a lot of funny fixed points used in Nixpkgs and that is challenging to think about.
Also, I don't understand how people can say the semantics is fine but the syntax is challenging. Syntax is entirely superficial. And if you are having trouble reading the syntax, how can you be sure the semantics isn't challenging?
There are a lot of funny fixed points used in Nixpkgs and that is challenging to think about.
The Nix properties fit ideally with the domain it tries to solve:
- functional with no side effects (for the same imput you always supposed to get the exact same output); derivation is function of its inputs (e.g. source code, dependencies, compiler flags, architecture and so on) if none of them changes you're expecting to get the same file. Introducing side effects would remove this guarantee, and introduce bugs. - lazily evaluated - you can specify multiple things but Nix will process only the ones that are referenced, this makes weird experience that the code isn't executed from top to bottom (as most people would expect)
Those two things essentially makes the derivation declarative. You specify what derivation you want and what it needs (like dependencies) you can also use the language to transform the inputs to the way you like and still preserving the guarantee that if one dependency changes the project needs to be rebuilt.
- functional with no side effects (for the same imput you always supposed to get the exact same output); derivation is function of its inputs (e.g. source code, dependencies, compiler flags, architecture and so on) if none of them changes you're expecting to get the same file. Introducing side effects would remove this guarantee, and introduce bugs. - lazily evaluated - you can specify multiple things but Nix will process only the ones that are referenced, this makes weird experience that the code isn't executed from top to bottom (as most people would expect)
Those two things essentially makes the derivation declarative. You specify what derivation you want and what it needs (like dependencies) you can also use the language to transform the inputs to the way you like and still preserving the guarantee that if one dependency changes the project needs to be rebuilt.
I really hope nickel takes off.
As a nix-lang fan, I've been using dhall as a nix-like build system configuration language when I need to work outside of the nix ecosystem. I love its use of static typing, but it's not without its rough edges. Defining recursive types is not simple and writing configs which need to mix rigidly-typed domain knowledge with arbitrary loose json data can be very tricky.
It looks nickel's authors have these use cases in mind. I'm excited to keep an eye on this project.
As a nix-lang fan, I've been using dhall as a nix-like build system configuration language when I need to work outside of the nix ecosystem. I love its use of static typing, but it's not without its rough edges. Defining recursive types is not simple and writing configs which need to mix rigidly-typed domain knowledge with arbitrary loose json data can be very tricky.
It looks nickel's authors have these use cases in mind. I'm excited to keep an eye on this project.
The Nickel author is the Nix author or at least one of contributors (Eelco Dolstra) so as long as the project is successful it will likely be introduced back to Nix.
Edit: actually looking at contributions Yann Hamdaoui seems like the main contributor, but I saw Eelco contributing to it.
Edit: actually looking at contributions Yann Hamdaoui seems like the main contributor, but I saw Eelco contributing to it.
There is cuelang already, and it’s quite frankly fantastic (we use it in prod).
Cuelang may be nice for some domains, but it's not a sensible replacement for the Nix language. If it was ever replaced by Cuelang, fundamental Nix abstractions would go missing or become awkward to deal with due to lack of expressiveness.
The Nix language is functionally a Lisp. It just has curly braces for sets/records, and like five keywords (e.g. with, inherit). If you learn a Lisp you'll basically know how to use Nix after reading about the syntactic differences. You can learn it in a day or two if you put in the effort, it's really not complex.
I think what people actually mean is that Nixpkgs is confusing, because that has a ton of weird utility/helper functions that you just need to know, esp. when it comes to what argument they take (which being dynamic doesn't help with at all) and Nixpkgs functions have historically had bad documentation.
I think what people actually mean is that Nixpkgs is confusing, because that has a ton of weird utility/helper functions that you just need to know, esp. when it comes to what argument they take (which being dynamic doesn't help with at all) and Nixpkgs functions have historically had bad documentation.
> It's way saner that the Nix custom language.
Strongly disagree. The Nix custom language is just basically JSON + lambda functions. Way easier to deal with and understand then the mess of the Scheme ecosystem(s).
Strongly disagree. The Nix custom language is just basically JSON + lambda functions. Way easier to deal with and understand then the mess of the Scheme ecosystem(s).
I honestly believe that Guix will eventually pull out ahead of NixOS, simply because its going to be part of Debian 11. NixOS is a bit easier to set up and use for now, especially for provisioning simple linux servers around commonly used packages.
I feel the same way.
One interesting architectural difference between Guix and Nix is there is no separation in Guix like what you see with Nix and nixpkgs. Guix and the packages are all just one massive repo of scheme. For Guix this tighter integration can be a development advantage. I cannot imagine how this can benefit targeting multiple platforms, which Nix is able to do with Linux, Mac, FreeBSD (as of 2020), yet somehow, Guix is able to pull off cross-platform support for GNU Hurd.
One interesting architectural difference between Guix and Nix is there is no separation in Guix like what you see with Nix and nixpkgs. Guix and the packages are all just one massive repo of scheme. For Guix this tighter integration can be a development advantage. I cannot imagine how this can benefit targeting multiple platforms, which Nix is able to do with Linux, Mac, FreeBSD (as of 2020), yet somehow, Guix is able to pull off cross-platform support for GNU Hurd.
> there is no separation in Guix like what you see with Nix and nixpkgs.
What separation is there in Nix? The whole system is just a big derivation the same way as a small package is.
What separation is there in Nix? The whole system is just a big derivation the same way as a small package is.
Layering between Nix, Nixpkgs, NixOS. And within Nix more emphasis on layering too (store vs nix language0.
Im not sure. Ive switched from nixos to guix, and i think nix's main advantage is just "a **tonne of code" for a wide variety of services, but guix allows new services and things much easier imo
Can you elaborate on this? Are you saying vanilla Debian will use Guix?
I heard somewhere that they are going to include it in the distro, so no guix deploy afaik, just the package manager itself as a package you can install. This should bring a lot more attention to the project at least.
Nix will also be in Debian Bullseye: https://packages.debian.org/bullseye/nix-setup-systemd
If you have the guix package manager you also have `guix deploy`
Guix is now in debian and apt-installable in ubuntu 21.04. Installation was the biggest hurdle, and there are still some quirks even with the debian installation--- you've got to set up your shell environment correctly to use it--- but in general it's super easy.
Practical questions: I’d love to try this out for my personal desktop/laptop, but I’ve been really pampered by the Arch repositories. What is the extent of completeness in supporting practically important daily use software? Are there parallel repositories supporting the non-libre packages that one might occasionally need? Is there an easy way to construct Guix recipes from another Linux system — say Debian, or Fedora or Arch?
The main guix "channel" (that's what it's called) contains more than 17.000 packages. Some software is hard to package, but I can't think of anything that's missing from the repository. You can have a look at the list of packages at https://guix.gnu.org/en/packages/ (note that firefox for instance is called icecat and based on the ESR version).
There are no other official channels, but a bunch of people have their own channels with additional packages. The most popular is probably nonguix (https://gitlab.com/nonguix/nonguix) which provides some popular nonfree packages.
Creating a recipe is generally easy (it's just a bunch of metadata) and even easier if it's supported by one of the importers (python, perl, emacs, ...). You can use guix on any other Linux system if you're not ready to install the complete system. The only difference is that your system is not managed by guix, and you can't run "guix system reconfigure", but the experience is otherwise the same. Make sure to follow the additional steps from the manual.
There are no other official channels, but a bunch of people have their own channels with additional packages. The most popular is probably nonguix (https://gitlab.com/nonguix/nonguix) which provides some popular nonfree packages.
Creating a recipe is generally easy (it's just a bunch of metadata) and even easier if it's supported by one of the importers (python, perl, emacs, ...). You can use guix on any other Linux system if you're not ready to install the complete system. The only difference is that your system is not managed by guix, and you can't run "guix system reconfigure", but the experience is otherwise the same. Make sure to follow the additional steps from the manual.
I use Guix as my daily driver and do occassionally come across software that hasn't been packaged. The big ones for my work that immediately come to mind are:
- slack
- kubectl
- terraform
- azure-cli
- cscope
There have been a several other missing tools for personal use that I just ended up packaging and sharing upstream. For the ones listed above, though, I just haven't gotten around to it, so I let Nix fill in the gap, hehe. FWIW, Guix already has Nix packaged and available as a service, so having parallel stores is really straightforward.
- slack
- kubectl
- terraform
- azure-cli
- cscope
There have been a several other missing tools for personal use that I just ended up packaging and sharing upstream. For the ones listed above, though, I just haven't gotten around to it, so I let Nix fill in the gap, hehe. FWIW, Guix already has Nix packaged and available as a service, so having parallel stores is really straightforward.
How in the world would I have discovered Firefox by that name? In retro, I find the trusted words kind of fun. But... How?
Icecat is a fork of Firefox to rid it of proprietary services and DRM. It's got a different name because Mozilla forbids (or used to forbid) redistribution with patches.
Debian also used to do this until Mozilla changed their tune on a few things. Debian's version and Icecat both used to be named IceWeasel, though, making fun of Mozilla.
Debian also used to do this until Mozilla changed their tune on a few things. Debian's version and Icecat both used to be named IceWeasel, though, making fun of Mozilla.
Thanks; great to hear about the 17k packages and the "nonguix" channel!
Guix is pretty cool, and I'll probably switch to it one day.
But as of now, it lacks some basic stuff like KDE suit. The nonguix channel AFAIK doesn't have binary builds so you'll be building quite a few packages yourself. Using nonguix also means you can't expect support in official support channels. Just something to know before you start.
But as of now, it lacks some basic stuff like KDE suit. The nonguix channel AFAIK doesn't have binary builds so you'll be building quite a few packages yourself. Using nonguix also means you can't expect support in official support channels. Just something to know before you start.
Using nonguix also means you can't expect support in official support channels. Just something to know before you start.
If this is true, it is a deal breaker for me. I try to buy open source hardware when I can, but even systems like the Pinebook Pro will have their functionality significantly limited by the absence of the linux-firmware package. It is a simple fact that most common WiFi chipset require non-free firmware.
If this is true, it is a deal breaker for me. I try to buy open source hardware when I can, but even systems like the Pinebook Pro will have their functionality significantly limited by the absence of the linux-firmware package. It is a simple fact that most common WiFi chipset require non-free firmware.
That's not true. You get support for the part of the guix system that is free software from guix, and support for what comes from nonguix, from nonguix. So if you have issues with the proprietary driver, you talk about it on #nonguix, but if you have troubles with guix, you talk about it on official channels like #guix.
Thanks for the clarification. That sounds like a much more reasonable policy.
nonguix channel AFAIK doesn't have binary builds so you'll be building quite a few packages yourself
There is a nonguix substitution server - https://mirror.brielmaier.net
Thank you for this! Missing KDE is a dealbreaker for primary system, but I can start using nonguix for older systems now.
Edit: I'm not sure if I'm reading this right, but the job says 0 builds (eg. https://mirror.brielmaier.net/eval/97958?status=succeeded&pa...). I'm not familiar with how guix works, but where can I see list of actual built derivations for a particular job?
Edit: I'm not sure if I'm reading this right, but the job says 0 builds (eg. https://mirror.brielmaier.net/eval/97958?status=succeeded&pa...). I'm not familiar with how guix works, but where can I see list of actual built derivations for a particular job?
It depends on your priorities. If you care about package availability and the broader ecosystem, Nix would be a better choice[1]. Nix has a larger community size, lower barrier for participation, and is more forgiving regarding non-free software. Its package count likely exceeds the AUR too, if you exclude duplicates.
Guix, on the other hand, is better suited for the more adventurous folks. It's built on Scheme, which many find appealing.
Both Nix and Guix can be installed on other Linux distros. Both are now available in the official Debian repository. Additionally, Nix supports macOS quite well. It even supports FreeBSD and Cygwin too, although it's probably not as mature.
[1]: https://repology.org/repositories/graphs
Guix, on the other hand, is better suited for the more adventurous folks. It's built on Scheme, which many find appealing.
Both Nix and Guix can be installed on other Linux distros. Both are now available in the official Debian repository. Additionally, Nix supports macOS quite well. It even supports FreeBSD and Cygwin too, although it's probably not as mature.
[1]: https://repology.org/repositories/graphs
Guix combines the specification language, API, and base distribution into a single monorepo. This makes it a bit like the linux kernel in terms of scope and ability to adapt and update itself without external dependencies. My understanding was that this wasn't quite the same for Nix, and that's led to some trickiness in the way that the project evolves. What do you think?
As a user who occasionally makes my own packages for software deployment, I can learn very quickly how to write a package description by grepping through the guix main repo and looking at how other packages are written. That's probably similar for Nix, but it's something that I found refreshingly clean and flat in guix and I'm frankly hooked.
As a user who occasionally makes my own packages for software deployment, I can learn very quickly how to write a package description by grepping through the guix main repo and looking at how other packages are written. That's probably similar for Nix, but it's something that I found refreshingly clean and flat in guix and I'm frankly hooked.
Guix and guile are in separate repositories just like nixpkgs and nix.. It wouldn't be nice to mix these. The difference is really about the amount of coevolving the language can make to the specific tasks.
You can run guix on top of Arch, which would let you try it with really easy fallback, at the expense of duplicate disk use and maintenance.
Thanks; this sounds interesting. Could you please link to any documentation or HOWTO?
Considering I have all my daily use software already installed in Arch, if I attempted to re-install them with Guix in parallel, would that lead to namespace collisions? (i.e. would I have to uninstall currently installed software before I re-install them with Guix?)
Considering I have all my daily use software already installed in Arch, if I attempted to re-install them with Guix in parallel, would that lead to namespace collisions? (i.e. would I have to uninstall currently installed software before I re-install them with Guix?)
> Could you please link to any documentation or HOWTO?
Here you go: https://guix.gnu.org/manual/en/html_node/Binary-Installation...
> if I attempted to re-install software with Guix in parallel, would that lead to namespace collisions?
It shouldn't. That's one thing Guix (and Nix) excel at: packages only refer to specific versions of their inputs, so you can even install multiple versions of the same package at once if you want.
In terms of Guix shadowing packages installed by Arch, you can put $HOME/.guix-profile either at the front or the end of your $PATH depending on whether you want to prioritize Guix or Arch packages. When I was getting my feet wet with Guix, I ran Guix on top of Gentoo (doing basically what you suggested, gradually shadowing Gentoo packages with Guix ones) for a few months without any significant problems.
Here you go: https://guix.gnu.org/manual/en/html_node/Binary-Installation...
> if I attempted to re-install software with Guix in parallel, would that lead to namespace collisions?
It shouldn't. That's one thing Guix (and Nix) excel at: packages only refer to specific versions of their inputs, so you can even install multiple versions of the same package at once if you want.
In terms of Guix shadowing packages installed by Arch, you can put $HOME/.guix-profile either at the front or the end of your $PATH depending on whether you want to prioritize Guix or Arch packages. When I was getting my feet wet with Guix, I ran Guix on top of Gentoo (doing basically what you suggested, gradually shadowing Gentoo packages with Guix ones) for a few months without any significant problems.
> I ran Guix on top of Gentoo
Could I ask you to compare guix and portage? I'm not an expert in either, but it looks like guix provides very similar source builds with easier binary caching/substitution.
Could I ask you to compare guix and portage? I'm not an expert in either, but it looks like guix provides very similar source builds with easier binary caching/substitution.
I can compare. Ebuilds are nothing in comparison, and guix is much more flexible. What portage has over guix is the wealth of premade packages (for now)
https://guix.gnu.org/manual/en/html_node/Installation.html
Namespacing in this case is just adding the guix bin directory to your PATH; put it in front of your existing path to default to guix programs, or at the end to default to Arch. You can also just use an ad-hoc environment (https://guix.gnu.org/manual/en/html_node/Invoking-guix-envir...) to call guix packages at will without really installing them.
Namespacing in this case is just adding the guix bin directory to your PATH; put it in front of your existing path to default to guix programs, or at the end to default to Arch. You can also just use an ad-hoc environment (https://guix.gnu.org/manual/en/html_node/Invoking-guix-envir...) to call guix packages at will without really installing them.
Is anyone there using Guix as a daily driver? Is it stable? Would love to hear some user experiences.
I oscillate back and forth between guix and nix. They both do the same thing really well. Nix is more mature, has some amazing capabilities, and is kinda annoying in spots such as documentation. I end up browsing users' repos for both.
Guix is more elegant in ways such as guile versus nix the dsl, although the haskell underpinning of nix is very useful.
If you're a linux user willing to put in the time and play around then both are perfectly usable as daily drivers but they're both learning experiences as well.
Hard to say which will win out, probably both, with excellent interoperability.
They really are the future of os managment, they simplify abstractions of state and naming
Guix is more elegant in ways such as guile versus nix the dsl, although the haskell underpinning of nix is very useful.
If you're a linux user willing to put in the time and play around then both are perfectly usable as daily drivers but they're both learning experiences as well.
Hard to say which will win out, probably both, with excellent interoperability.
They really are the future of os managment, they simplify abstractions of state and naming
What kind of interoperability should I expect between Guix and Nix going forward? As I understand, Nix is pretty heavily reliant on systemd for running services while Guix has its own pid1. Last I read Guix was also replacing the daemon with one written in scheme. I think Guix used Nix package format (nar) at one point but not sure if that holds anymore either.
The idea of two functional, declarative package/system managers being interoperable is very exciting for me, if it meant I can use full breadth of Nixpkgs with system config declared in Guile. But is that something I can look forward to or is it too much?
The idea of two functional, declarative package/system managers being interoperable is very exciting for me, if it meant I can use full breadth of Nixpkgs with system config declared in Guile. But is that something I can look forward to or is it too much?
Nix exists as a service for guix. All my system declarations include the nix service. But as far as interop goes I’m not really sure of the value. I think it just sounds neat but hasn’t really been thought through in terms of exactly what that would look like.
> although the haskell underpinning of nix is very useful.
I thought Nix was written in C++?
I thought Nix was written in C++?
Nix itself is written in C++, but Nix the language borrows multiple characteristics from Haskell. Nix community and Haskell community are also very comfortable and comingled with each other and Nix is one of the recommended ways to manage Haskell project dependencies.
Haskell and the Nix language are both pure and lazy extensions of lambda calculus, but that's an enormous language space, and Nix's lack of static types makes them pretty distant.
For many Haskellers, I believe the interest stems from how Haskell's "cabal-install" (its closest equivalent to pip, cargo etc) used to be pretty broken. There wasn't universal interest in fixing this, with some insisting that installing dependencies is the job of your distro's package manager, not your language's ecosystem.
Gentoo did an okay job at having coverage of Haskell dependencies, but Nix was the clear leader ever since they could auto-import the hackage database. It's for this sole reason that I moved from Gentoo to Nix.
This pipeline I came through doesn't really exist now, because the Haskell community has endorsed Stackage, and cabal has fixed its core problems by copying the nix solution.
For many Haskellers, I believe the interest stems from how Haskell's "cabal-install" (its closest equivalent to pip, cargo etc) used to be pretty broken. There wasn't universal interest in fixing this, with some insisting that installing dependencies is the job of your distro's package manager, not your language's ecosystem.
Gentoo did an okay job at having coverage of Haskell dependencies, but Nix was the clear leader ever since they could auto-import the hackage database. It's for this sole reason that I moved from Gentoo to Nix.
This pipeline I came through doesn't really exist now, because the Haskell community has endorsed Stackage, and cabal has fixed its core problems by copying the nix solution.
Usually with esoteric distros you run into problems with binary packages and packages based on uncommonly used languages.
It'll probably work as a daily driver if you mainly live in a web browser and don't do GPGPU/games/new languages/etc. If you don't mind building from source you can even do most of those.
For what it's worth the project seems very well structured and the contributors very competent and motivated. I am tracking the project.
It'll probably work as a daily driver if you mainly live in a web browser and don't do GPGPU/games/new languages/etc. If you don't mind building from source you can even do most of those.
For what it's worth the project seems very well structured and the contributors very competent and motivated. I am tracking the project.
> if you mainly live in a web browser and don't do GPGPU
For what it's worth, I use Guix and I've been able to do everything but CUDA just fine. (CUDA will never be supported in Guix as it requires proprietary drivers to function.) There are opencl packages, for example. It works well enough to run an Ethereum miner, Blender, and even games in WINE. I've been meaning to package AMD ROCm for better GPU compute support.
For what it's worth, I use Guix and I've been able to do everything but CUDA just fine. (CUDA will never be supported in Guix as it requires proprietary drivers to function.) There are opencl packages, for example. It works well enough to run an Ethereum miner, Blender, and even games in WINE. I've been meaning to package AMD ROCm for better GPU compute support.
I, for one, would be happy to see that package.
Took a try at it awhile back and found it rather bumpy.
One of the issues I've run into with Nix was lack of OpenGL. Does Guix have similar issues?
Nix has OpenGL it just doesn't know how to find the driver on non NixOS distros by default, can fix it with this: https://github.com/guibou/nixGL
I use it as a package manager on another distro (in my case, popos; that's how a lot of people use it afaik). Considering using it as a VM. It works quite well as a supplementary package manager, but has glaring deficiencies with some languages / build systems (gradle, npm, Julia, etc.)
I do. See also #guix and #nonguix on libera
I have been wanting to try this for years, the idea of being able to easily move my complete daily machine to a new laptop sound pretty interesting.
What the best guide or documentation if that would be a my goal?
What the best guide or documentation if that would be a my goal?
If you're new to Guix, you probably want to start with the Guix Cookbook: https://guix.gnu.org/en/blog/tags/cookbook/en/guix-cookbook.... -- although I've never read it front-to-back myself, just skimmed it and used it as a reference thereafter.
Not sure if there's a full howto for your purpose, but you'd want to look into manifests: https://guix.gnu.org/en/blog/2019/guix-profiles-in-practice/
There is a guix command for generating a manifest from the current profile as well, but it's not mentioned in the above link: guix package --export-manifest
Not sure if there's a full howto for your purpose, but you'd want to look into manifests: https://guix.gnu.org/en/blog/2019/guix-profiles-in-practice/
There is a guix command for generating a manifest from the current profile as well, but it's not mentioned in the above link: guix package --export-manifest
How is Guix pronounced? Gicks or g-u-i-x or gooey-x?
[deleted]