Trying Guix: A Nixer's Impressions
Trying Guix: A Nixer's Impressions
tazjin's blog: Trying Guix: A Nixer's Impressions
One aspect of Guix I found to be really fascinating: That there is basically no conceptual difference between defining a package as a private build script, and using a package as part of the system.
Let me explain: Say you wrote a little program in Python which uses a C library (or a Rust library with C ABI) which is in the distribution. Then, in Guix you would put that librarie's name and needed version into a manifest.scm file which lists your dependency, and makes it available if you run guix shell in that folder. It does not matter whether you run the full Guix System, or just use Guix as s package manager.
Now, if you want to install your little python program as part of your system, you'll write an install script or package definition, which is nothing else than a litle piece of Scheme code which contains the name of your program, your dependency, and the information needed to call python's build tool.
The point I am making is now that the only thing which is different between your local package and a distributed package in Guix is that distributed packages are package definitions hosted in public git repos, called 'channels'. So, if you put your package's source into a github or codeberg repo, and the package definition into another repo, you now have published a package which is a part of Guix (in your own channel). Anybody who wants to install and run your package just needs your channel's URL and the packages name. It is a fully decentral system.
In short, in Guix you have built-in something like Arch's AUR, just in a much more elegant and clean manner - and in a fully decentralized way.
This is true for Nix as well.
The two main advantages of Guix are the language (which is well-known and comes with lots of good tooling and other support) and the package bootstrapping.
The main disadvantages I've faced when trying it a few years ago:
At the time it was a great concept, but essentially useless for anything not Emacs/Haskell related.
Yep. I feel like Guix is surprisingly awesome and polished in a couple places, but mostly it's a very DIY distro, much more so than even NixOS.
Yeah. See, drivers are part of the hardware abstraction layer which in a Linux system is the Kernel. The kernel is GPL, so it is hard to get support for hardware with drivers without GPL, it does not conform Linux' license.
I, too, had also nothing but hassle with an NVidia graphics card in Debian. It was a happy day when I finally ditched it for a supported card and had a fully supported system!
The other thing... let's turn the question around. Would you:
If not - why do some people expect equivalent things from free software projects?
It's very easy to add additional channels and non-official channels integrate pretty well into everything. I don't really notice if a package comes from an "official" channel or "non-official" channel.
https://toys.where-is.social/
Find different channels and substitute servers or create your own
I wouldn't call that an advantage for the average person. Nix is far nicer to work with. Some Lispers might disagree, but I, for one, can't exactly see the beauty in trying to turn Scheme into a configuration language with macros and hacks. Also Guix puts Scheme everywhere, things you can do with plain old Bash in Nix, you'll have to all do in Scheme in Guix, so there is a much steeper learning curve.
Well, Nix language is also full of hacks, idiosyncrasies and stupid decisions. I say that as someone who's writing it "professionally", i.e. as part of my job. Scheme is way less "unexpected". But there are other parts of Guix which are pretty weird or just bad, like the "channels"/"pins" management situation.
Scheme is a minimalistic Lisp dialect, and macros are central in Lisp. For example, they allow for both conditional evaluation ("if" is a macro, or more precisely, a "special form" that is used in other conditionals), and for delayed evaluation at run time, which matches a bit Nix being lazy.
Also, Scheme is designed as a not strictly but mostly functional language, favouring side-effect free functions, which matches well with the declarative task which is package definitions.
bash, in contrary, is not side-effect-free, it modifies its environment, and this is very much not desired in a functional package manager: it is at the core that package declarations are side-effect-free.
And Emacs shows that Lisp written in a declarative style is a superb configuration language. (There is now even a project to use a Scheme, Steel Scheme, to configure helix, a programmers text editor which has many many features stemming from vim!).
Bash is not a advantage, it's a disadvantage