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.
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.
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.
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.
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.
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.
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?
I usually carry a few stickers on me just in case, so people can remember OSM and look it up later (after I explain what I'm doing and say it's a fun community project).
What if there was a way to replace parenthesis with syntax? For instance, if you could declare your operating system as:
operating-system:
...
packages:
- vim
- %base-packages
instead of:
(operating-system
...
(packages (cons* vim %base-packages)))
would that help you? No more parenthesis, the complexity of cons* is hidden behind the "-" and it's pretty trivial to convert between one syntax and the other. If it was possible, how would that affect your opinion on guix? What if the installer came with a pre-configured vim for scheme?
btw, I'm also a guix and a vim user, and I don't use anything special for parenthesis. I just close them manually like a grown-up (which is a very usefull skill to have when you want to impress an emacs user :p).
Wisp provides a Python-like syntax for Scheme that gives you something very close to the above: http://draketo.de/english/wisp . (Though me and my editor don't view parentheses as an obstacle, quite the opposite...)
There you're replacing a configuration language that is executable Scheme, with what seems to be a declarative language, and converting to indentation syntax. That's a two-variable change.
The original S-exp syntax doesn't have to be an executable program in which you use Scheme operators like cons* .
The indentation-based notation, likewise, can retain the property that it's executable Scheme and reveals operations like cons* to the user.
The whole problem with that notation is that it isn't declarative. It's mean to execute. So to read it you have to know Guile functions like cons* . vim and packages% are actually variable bindings; vim undoubtedly stands for some package object defined elsewhere.
A Scheme-based configuration language that is executable Scheme is going to end up using the entire language, and be daunting to some IT person who just wants to reconfigure the distro and isn't a Scheme programmer. (Counterargument: a clean, dedicated configuration template language will likely sprout a way to run arbitrary Scheme code anyway.)
It's tempting to make things like this because they are quick and dirty. For instance, we could make an assembly language which is like this. (mov eax ebx) could be a call to a function called mov, and eax and ebx could be constants in Scheme itself. The function has the side effect of emitting the assembled code into some stream. We don't have to write any code which would walk, validate and translate the syntax of a Lisp-ified assembly language; we just let the programmer write code using the API we have provided and throw it into the path of the evaluator.
And we can have fun like (dotimes 13 (roll %ecx)) to emit 13 copies of an instruction.
Same here, only one app, Anki, took the time to inform me they had changed their privacy policy (although they didn't block my account before I accepted the changes).
I don't think they have less trackers. I think it's even easier to unintentionnaly add a tracker to an app because some of them come with dependencies when you're not careful. See https://reports.exodus-privacy.eu.org/reports/ for some reports on what tracker typical apps use.
https://framagit.org/tyreunom/guix-android